openfoam merge requestshttps://develop.openfoam.com/Development/openfoam//merge_requests20191210T15:53:15Zhttps://develop.openfoam.com/Development/openfoam//merge_requests/301Feature particle patch postpro filtering20191210T15:53:15ZAndrew HeatherFeature particle patch postpro filtering### Summary
Adds options to write particlepatch interactions to file, and to select particle fields to postprocess for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new mode...### Summary
Adds options to write particlepatch interactions to file, and to select particle fields to postprocess 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
(
"(wallscyc.*)"
{
type rebound;
}
"inletoutlet"
{
type escape;
}
);
// New optional entry
writeToFile yes;
}
```
Cloud function objects:
New `fields` optional entry can be used to select which particle fields to postprocess; 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 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 Heatherhttps://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/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/271lumped point motion using local linear basic functions (#1341)20200617T14:15:52ZMark OLESENlumped point motion using local linear basic functions (#1341)Extends lumped point motion to support multiple connectivity.
Examples include structures such as bridges.Extends lumped point motion to support multiple connectivity.
Examples include structures such as bridges.v2006Andrew HeatherAndrew Heatherhttps://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/257Introduced changes required to make isoAdvector and interIsoFoam work with...20190613T20: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/238WIP: functionObject: Lamb Vector and its Divergence20190214T12:10:31ZKutalmış BerçinWIP: functionObject: Lamb Vector and its Divergence### Summary
Potential VW SubProject: Lamb Vector and its Divergence functionObject.
Lamb vector is the crossproduct of vorticity and velocity.
The motivation to do so stems from the close connection between the Lamb vector div...### Summary
Potential VW SubProject: Lamb Vector and its Divergence functionObject.
Lamb vector is the crossproduct of vorticity and velocity.
The motivation to do so stems from the close connection between the Lamb vector divergence and the motions in a flow, especially those instantaneous motions in turbulent flows, having a distinctively high capacity to effect a time rate of change of momentum, and generate forces such as drag.
### Resolved bugs (If applicable)
N/A
### Details of new models (If applicable)
Verification, hence pictures, will be provided based on the plane channel flow cases reported the journal paper below:
The Lamb vector divergence in Navier–Stokes flows, J. Fluid Mech. (2008), vol. 610, pp. 261–284., doi:10.1017/S0022112008002760O
### Risks
Not that I know of.https://develop.openfoam.com/Development/openfoam//merge_requests/236Feature postpro20190220T19:43:43ZMark OLESENFeature postpro### Summary
Extension of insitu visualization (runTimePostProcessing):
 parallel rendering
 direct use of VTK cutting plane and isosurface 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 isosurface 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 persurface 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/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/231Function object updates20190131T17: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;
}
\endverbatimv1906AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/228Feature run time control triggers20190124T05: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 1e3;
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/225ENH: Added new AMIWeights function object20181210T09:55:04ZAdminENH: Added new AMIWeights function objectReports the minmaxaverage AMI weights to text file and optionally
writes VTK surfaces of the sum of the weights, and mask field for
ACMI patches.
Example usage:
AMIWeights
{
type AMIWeights;
libs ...Reports the minmaxaverage AMI weights to text file and optionally
writes VTK surfaces of the sum of the weights, and mask field for
ACMI patches.
Example usage:
AMIWeights
{
type AMIWeights;
libs ("libfieldFunctionObjects.so");
writeControl writeTime;
writeFields yes;
}v1812AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/217Workpackage09 geometric constraint20181108T20:50:48ZMark OLESENWorkpackage09 geometric constraintThe geometric decomposition constraint (issue #921) may be used to restrict the mesh decomposition on a geometrical basis.
For example, to avoid splitting of a sensitive feature across processor boundaries.
The geometry constraints are...The geometric decomposition constraint (issue #921) may be used to restrict the mesh decomposition on a geometrical basis.
For example, to avoid splitting of a sensitive feature across processor boundaries.
The geometry constraints are described by topoSet face sources, which can include basic geometrically entities (sphere, box, cylinder), mesh entities (eg, faces associated with a cellSet) or an arbitrary closed surface (stl, obj, etc). The support for arbitrary closed surfaces uses a triSurfaceMesh topoSetFaceSource.v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/213Feature vtm/vtk20181126T10:30:41ZMark OLESENFeature vtm/vtkIncludes numerous modifications to the VTKrelated infrastructure. Notably it adds parallel output for foamToVTK and for the vtkWrite function object. Multiregion, multiblock VTM output with associated timeseries files. TimeValue time...Includes numerous modifications to the VTKrelated infrastructure. Notably it adds parallel output for foamToVTK and for the vtkWrite function object. Multiregion, multiblock VTM output with associated timeseries files. TimeValue timestamps within all the generated files. Improvements to the vtkCloud and vtkWrite function objects to allow selection of regions of interest.v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/210Feature processor level of detail (LOD)20180625T07:55:22ZAdminFeature processor level of detail (LOD)Adds a new method to calculate processor distribution maps as an alternative to the AABBTree; currently available to the mapFieldsPar utility via a new command line optionAdds a new method to calculate processor distribution maps as an alternative to the AABBTree; currently available to the mapFieldsPar utility via a new command line optionv1806https://develop.openfoam.com/Development/openfoam//merge_requests/206ENH: vtkCloud function object (issue #866)20180618T12:22:37ZMark OLESENENH: vtkCloud function object (issue #866) writes lagrangian data in VTP format during a simulation.
In parallel, all data are written from the master.
 also emits a file series (supported by paraview 5.5 and later), which helps maintain a correspondence between VTK files a... writes lagrangian data in VTP format during a simulation.
In parallel, all data are written from the master.
 also emits a file series (supported by paraview 5.5 and later), which helps maintain a correspondence between VTK files and their time values.v1806AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/200ENH: new bitSet class and improved PackedList class (closes #751)20180425T10:40:00ZMark OLESENENH: new bitSet class and improved PackedList class (closes #751) The bitSet class replaces the old PackedBoolList class.
The redesign provides better blockwise access and reduced method
calls. This helps both in cases where the bitSet may be relatively
sparse, and in cases where advantage ... The bitSet class replaces the old PackedBoolList class.
The redesign provides better blockwise access and reduced method
calls. This helps both in cases where the bitSet may be relatively
sparse, and in cases where advantage of contiguous operations can be
made. This makes it easier to work with a bitSet as toplevel object.
In addition to the previously available count() method to determine
if a bitSet is being used, now have simpler queries:
 all()  true if all bits in the addressable range are empty
 any()  true if any bits are set at all.
 none()  true if no bits are set.
These are faster than count() and allow early termination.
The new test() method tests the value of a single bit position and
returns a bool without any ambiguity caused by the return type
(like the get() method), nor the const/nonconst access (like
operator[] has). The name corresponds to what std::bitset uses.
The new find_first(), find_last(), find_next() methods provide a faster
means of searching for bits that are set.
This can be especially useful when using a bitSet to control an
conditional:
OLD (with macro):
forAll(selected, celli)
{
if (selected[celli])
{
sumVol += mesh_.cellVolumes()[celli];
}
}
NEW (with const_iterator):
for (const label celli : selected)
{
sumVol += mesh_.cellVolumes()[celli];
}
or manually
for
(
label celli = selected.find_first();
celli != 1;
celli = selected.find_next()
)
{
sumVol += mesh_.cellVolumes()[celli];
}
 When marking up contiguous parts of a bitset, an interval can be
represented more efficiently as a labelRange of start/size.
For example,
OLD:
if (isA<processorPolyPatch>(pp))
{
forAll(pp, i)
{
ignoreFaces.set(i);
}
}
NEW:
if (isA<processorPolyPatch>(pp))
{
ignoreFaces.set(pp.range());
}
v1806AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/195Feature catalyst20180403T19:22:48ZMark OLESENFeature catalystIntegration of ParaView Catalyst (issue #705) via a function object.Integration of ParaView Catalyst (issue #705) via a function object.v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/182WIP: Integration of IH Cantabria wave modelling contributions20191003T10:38:02ZAdminWIP: Integration of IH Cantabria wave modelling contributions## New code
New wave generation model:
 `streamFunction`: based on Fenton's Fourier approximation
New interFoambased solver:
 `interPorousFoam`: alternative method to include porosity effects, to be used with new `fvOptions` (se...## New code
New wave generation model:
 `streamFunction`: based on Fenton's Fourier approximation
New interFoambased solver:
 `interPorousFoam`: alternative method to include porosity effects, to be used with new `fvOptions` (see below)
New `fvOptions`:
 `multiphasePorositySource`: porosity for multiphase flows
 `mangrovesSource`: mangrove interaction, i.e. drag and turbulence contributions for kepsilon based models
## Test cases:
 interPorousFoam/porousDamBreak
 interPorousFoam/mangroves
## References:
Solitary wave attenuation by vegetation patches.
Maza, M, Lara, J.L., & Losada, I.J. (2016)
Advances in Water Resources. Vol.98, pp. 159172
https://doi.org/10.1016/j.advwatres.2016.10.021
Tsunami wave interaction with mangrove forests: A 3D numerical approach.
Maza, M, Lara, J.L., & Losada, I.J. (2015)
Coastal Engineering. Vol.98, pp. 3354
https://doi.org/10.1016/j.coastaleng.2015.01.002
## Code integration
 Initial code supplied in commits e0682d67 and 2124eb88; and integrated into OpenFOAM by OpenCFDv1712AdminAdmin