openfoam merge requestshttps://develop.openfoam.com/Development/openfoam//merge_requests20171130T08:46:44Zhttps://develop.openfoam.com/Development/openfoam//merge_requests/174consolidate surfaceFormats for reading/writing triSurface20171130T08:46:44ZMark OLESENconsolidate surfaceFormats for reading/writing triSurface eliminates previous code duplication and improves maintainability
 issue #294
 eliminates previous code duplication and improves maintainability
 issue #294
v1712AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/349CONT: Addition of compressibleIsoInterFoam and PLIC20200622T11:17:41ZSergio FerrarisCONT: Addition of compressibleIsoInterFoam and PLICContribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tuto...Contribution by Henning Scheufler and Johan Roenby. Headers reviewed. Rebased to the latest develop.
1) Implementation of the compressibleIsoInterFOam solver
2) Implementation of a new PLIC interpolation scheme.
3) New tutorials associated with the solvers
This implementation was carried out by Henning Scheufler (DLR) and Johan
Roenby (DHI), following :
\verbatim
Henning Scheufler, Johan Roenby,
Accurate and efficient surface reconstruction from volume fraction data
on general meshes, Journal of Computational Physics, 2019, doi
10.1016/j.jcp.2019.01.009
\endverbatim
The integration of the code was carried out by Andy Heather and Sergio
Ferraris from OpenCFD Ltd.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/28CONTRIBUTION: Turbulence  updated SpalartAlmaras & kOmegaSST DES, DDES and I...20151222T22:14:56ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comCONTRIBUTION: Turbulence  updated SpalartAlmaras & kOmegaSST DES, DDES and IDDESCode supplied by CFD Software E+F GmbHCode supplied by CFD Software E+F GmbHAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/211coordinate system improvements20181011T15:32:04ZMark OLESENcoordinate system improvementsReworked coordinate systems and rotations API.Reworked coordinate systems and rotations API.v1812Mattijs Janssens4Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam//merge_requests/391corrections and improvements for Function120201120T15:18:27ZMark OLESENcorrections and improvements for Function1 easier support for nonmandatory functions.
 support for compatibility lookups
 support frequency or period for Sine/Cosine/Square Function1 easier support for nonmandatory functions.
 support for compatibility lookups
 support frequency or period for Sine/Cosine/Square Function1v2012Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/319DEFEATURE: deprecate v2f model in favour of kEpsilonPhitF20200103T09:41:19ZKutalmış BerçinDEFEATURE: deprecate v2f model in favour of kEpsilonPhitF kEpsilonPhitF is a kEpsilonbased model which originated
from (Durbin, 1995)’s v2f methodology. However, the majority of
v2f model variants proved to be numerically stiff for segregated
solution algorithms due to the coup... kEpsilonPhitF is a kEpsilonbased model which originated
from (Durbin, 1995)’s v2f methodology. However, the majority of
v2f model variants proved to be numerically stiff for segregated
solution algorithms due to the coupled formulations of v2 and f fields,
particularly on wall boundaries.
The v2f variant (i.e. OpenFOAM’s v2f model) due to
(Lien and Kalitzin, 2001) reformulated the original v2f model to enable
segregated computations; however, a number of shortcomings regarding
the model fidelity were reported in the literature.
To overcome the shortcomings of the v2f methodology, the v2f approach
was reevaluated by (Laurence et al., 2005) by transforming v2 scale into
its equivalent nondimensional form, i.e. phit, to reduce the numerical
stiffness.
This variant, i.e. kEpsilonPhitF, is believed to provide numerical
robustness, and insensitivity to grid anomalies while retaining the
theoretical model fidelity of the original v2f model.
Accordingly the v2f RANS model is deprecated in favour of the variant
kEpsilonPhitF model.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/162dictionary compatibility/migration methods20171108T19:55:08ZMark OLESENdictionary compatibility/migration methods additional methods for handling changed keywords between version.
 old keywords are tagged with the version number to allow future culling of old content.
 minor adjustments to dictionary add/set method to make it easier to build sub... additional methods for handling changed keywords between version.
 old keywords are tagged with the version number to allow future culling of old content.
 minor adjustments to dictionary add/set method to make it easier to build sub dictionaries onthefly without copying.v1712Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/105Dict lookup20170502T15:37:58ZMark OLESENDict lookupVersion v1706AdminAdminhttps://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/348DOC: Elaborate the usage of function objects20200608T14:44:34ZKutalmış BerçinDOC: Elaborate the usage of function objects### Summary
Documentation and usage examples are limited for some of the function objects. This somewhat hampers the efforts of users to access all capabilities of them.
Therefore, we decided to elaborate the usage of function obje...### Summary
Documentation and usage examples are limited for some of the function objects. This somewhat hampers the efforts of users to access all capabilities of them.
Therefore, we decided to elaborate the usage of function objectcs in:
 Extended Code Guide (comprises the full spectrum of details)
 Header files (comprises the minimal set of info, directing the users to the central info hub, the Extended Code Guide)
In parallel to the `Extended Code Guide` improvements (corresponding: [Extended Code Guide:docFOspart1](https://develop.openfoam.com/Documentation/ExtendedCodeDocumentation/tree/docFOspart1)), it is useful:
 to provide a minimal documentation in the header files of the function objects
 to provide at least one example of usage per function object in tutorials
In addition, style/implementation consistency across function objects can be imposed for:
 update libs of etc/caseDicts/postProcess items
 ensure `destructor=default`
 ensure `no copy construct`/`no copy assignment`
 static data members
 ensure constness
 change `lookupOrDefault()` to `getOrDefault()`
### Resolved bugs
#1594
### Risks
Considerably low.
Regression tests are pending.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/361DOC: Elaborate the usage of topoSet20200608T14:52:12ZKutalmış BerçinDOC: Elaborate the usage of topoSet### Summary
Documentation and usage examples for `topoSet` are considerably improved.
### Risks
Considerably low.### Summary
Documentation and usage examples for `topoSet` are considerably improved.
### Risks
Considerably low.v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/370DOCSTYLE: various release changes20200616T12:50:23ZKutalmış BerçinDOCSTYLE: various release changes Headerfile documentation of various new functionalities was moved to the Extended Code Guide.
 Various corrections to the clashes in release commits #1726 Headerfile documentation of various new functionalities was moved to the Extended Code Guide.
 Various corrections to the clashes in release commits #1726v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/517Draft: ENH: PatchInjectionModel  added new parcel initial velocity options20211214T14:15:55ZAndrew HeatherDraft: ENH: PatchInjectionModel  added new parcel initial velocity optionsThe parcel initial velocity can now be set using the new `velocityType`
entry, taking one of the following options:
 fixedValue : (default) same as earlier versions, requires U0
 patchValue : velocity set to seed patch face value
...The parcel initial velocity can now be set using the new `velocityType`
entry, taking one of the following options:
 fixedValue : (default) same as earlier versions, requires U0
 patchValue : velocity set to seed patch face value
 zeroGradient : velocity set to seed patch face adjacent cell value
Example usage:
model1
{
type patchInjection;
massTotal 1;
SOI 0;
parcelBasisType mass;
patch cylinder;
duration 10;
parcelsPerSecond 100;
velocityType patchValue;
//velocityType zeroGradient;
//U0 (10 0 0);
flowRateProfile constant 1;
sizeDistribution
{
type normal;
normalDistribution
{
expectation 1e3;
variance 1e4;
minValue 1e5;
maxValue 2e3;
}
}
}
See the new $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk tutorialv2112https://develop.openfoam.com/Development/openfoam//merge_requests/472Draft: ENH: relative velocity usage for porosity in MRF regions20211215T10:52:37ZAndrew HeatherDraft: ENH: relative velocity usage for porosity in MRF regionsRelated to #1652  updates porosity calculation when used with MRF to use relative velocity
Test case from bug report: [rotatingCylinderstest.tgz](/uploads/49641463ba3d523874517a126aa32293/rotatingCylinderstest.tgz)Related to #1652  updates porosity calculation when used with MRF to use relative velocity
Test case from bug report: [rotatingCylinderstest.tgz](/uploads/49641463ba3d523874517a126aa32293/rotatingCylinderstest.tgz)v2212Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam//merge_requests/525Draft: Extend splitMeshRegions to automatically create AMI interregion patches20220217T12:01:17ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comDraft: Extend splitMeshRegions to automatically create AMI interregion patches### Summary
splitMeshRegions by default creates onetoone mapped patches between regions. This adds the option to generate AMI type mapped patches instead.
### Resolved bugs (If applicable)
#2251
### Details of new models (If appl...### Summary
splitMeshRegions by default creates onetoone mapped patches between regions. This adds the option to generate AMI type mapped patches instead.
### Resolved bugs (If applicable)
#2251
### Details of new models (If applicable)
The new functionality is through the `autoPatch` command line option:
```
splitMeshRegions autoPatch '(myInterfaces*)'
```
This will detect disconnected regions of the mesh and will attempt matching the 'myInterfaces*' patches using an AMI method. Any successful match will result in the matching faces to be put into a mapped type patch with `nearestPatchFaceAMI` as the interregion mapping method.
### Risks
The logic is a bit more complex. There are unknowns about the behaviour of AMI type matching (it currently has no distance limit) but a different AMI matching method can be used using the `AMIMethod` option.Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/392Draft: Feature ep1364 fan curve clipping20201216T17:13:16ZMark OLESENDraft: Feature ep1364 fan curve clippinghttps://develop.openfoam.com/Development/openfoam//merge_requests/390draft: Feature streams20210429T08:25:16ZMark OLESENdraft: Feature streamsAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam//merge_requests/415Draft: Integration of PDRfitMesh20211110T14:26:44ZMark OLESENDraft: Integration of PDRfitMeshhttps://develop.openfoam.com/Development/openfoam//merge_requests/555Draft: overset modifications: allow overset pacthes overlap, allow fringe fac...20220811T13:25:14ZSergio FerrarisDraft: overset 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 Up 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 precondition 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.Mattijs Janssens4Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam//merge_requests/526Draft: Resolve "ENH: cyclicACMI have optional search distance"20220601T08:14:25ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comDraft: Resolve "ENH: cyclicACMI have optional search distance"Closes #2378Closes #2378Mattijs Janssens4Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4Mattijs@users.noreply.develop.openfoam.com