openfoam merge requestshttps://develop.openfoam.com/Development/openfoam//merge_requests20190612T11:17:39Zhttps://develop.openfoam.com/Development/openfoam//merge_requests/251WIP: Feature matrix cleanup20190612T11:17:39ZKutalmış BerçinWIP: Feature matrix cleanupAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/250WIP: ENH: Reforms QRMatrix class20190328T10:15:45ZKutalmış BerçinWIP: ENH: Reforms QRMatrix class* If applied:
* Fixes issue #1240
* New TestQRMatrix.C for 3 input scenarios
* Class output verified via NumPy, aka LAPACAK routines
* Improves header documentation
* Corrects Doxygen parsing problems, i.e. //
* Alig...* If applied:
* Fixes issue #1240
* New TestQRMatrix.C for 3 input scenarios
* Class output verified via NumPy, aka LAPACAK routines
* Improves header documentation
* Corrects Doxygen parsing problems, i.e. //
* Aligns code style with the code style guide
* Applicable to Foam::complex template
* Verification: See [QRMatrix_Verifications.pdf](/uploads/1d645aa179f043a51aea6302aed254f4/QRMatrix_Verifications.pdf) for NumPy comparisons.
* Future work:
* Refactoring is possible if new Matrix class functions applied
* For few matrix elements, NumPy and OpenFOAM yielded fewdecimal point differences
* //Info<< "M*x  b:" << nl << (M*x  source) << endl; affects the subsequent program states despite encapsulation. Memory leak might be the reason, will be checked
@markAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/249Snappy hex mesh proximity check20190325T16:49:51ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comSnappy hex mesh proximity checkAdds snappyHexMesh functionality to remove cells in small gaps (instead of refining them).
See mesh/snappyHexMesh/opposite_walls tutorial.Adds snappyHexMesh functionality to remove cells in small gaps (instead of refining them).
See mesh/snappyHexMesh/opposite_walls tutorial.AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/248ENH: Add reconstructPar into Allrun (Issue #1244)20190322T20:02:29ZKutalmış BerçinENH: Add reconstructPar into Allrun (Issue #1244) If applied: tut/multiphase/interIsoFoam/iobasin/Allrun
will execute 'runApplication reconstructPar'
 Why: Prior to this change, no reconstructPar was executed
despite the parallel run
 Related: Issue #1244 If applied: tut/multiphase/interIsoFoam/iobasin/Allrun
will execute 'runApplication reconstructPar'
 Why: Prior to this change, no reconstructPar was executed
despite the parallel run
 Related: Issue #1244Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/247ENH: Function1 type support for rpm specification. Fixes #124520190326T05:48:05ZPrashant SonakarENH: Function1 type support for rpm specification. Fixes #1245https://develop.openfoam.com/Development/openfoam//merge_requests/246ENH: functionObject: refactored coordinate system usage and new forceCoeffs ...20190613T14:47:10ZKutalmış BerçinENH: functionObject: refactored coordinate 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 valgrindmemcheck
* 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/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/244WIP: Feature euler euler solvers. Integration of Euler solvers.20200713T17:38:14ZSergio FerrarisWIP: Feature euler euler solvers. Integration of Euler solvers.### Summary
New chtMultiRegionTwoPhaseEulerFoam solver, plus corresponding BC's
Integrated MULES and CMULES new interfaces and the corresponding multiphase solvers
multiphase tutorials not tested/updated
New library src/phaseSystemModels...### Summary
New chtMultiRegionTwoPhaseEulerFoam solver, plus corresponding BC's
Integrated MULES and CMULES new interfaces and the corresponding multiphase solvers
multiphase tutorials not tested/updated
New library src/phaseSystemModels for all the phases systems, submodels, BC's, turbulence. This
lib was taken out of the Euler solvers and located on /src
This branch was not rebased on the latest develop as it needs several more updates first
(including headers).
Work to do:
1) Review latest form org for the phases modeling.
2) Review latest tutorial entries
### Details of new models (If applicable)
chtMultiRegionTwoPhaseEulerFoam and the extended alphaBoilingWall BC is designed to deal
with several cooling regimes:
single phase
subcooled nucleate wall boiling
transitional boiling
film boiling.
The wall function uses a partition method to transfer heat either
to the liquid or vapor phase. At the moment, this function works
in a wall temperature fixed mode. i.e, there is no consideration
for the sudden change of heat transfer coefficient (htc) after
reaching TDBN (deviation from nucleate boiling temperature)
More details on alphatWallBoilingWallFunctionFvPatchScalarField.C
### Risks
Need to test all the multiphase tutorials due to significant changes from the last year
and some changes this year from org. This should be done when the merge is completed.v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/243Feature reflective solar load20190502T09: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 multiband 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/242Reacting heterogeneous cloud20190502T18: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/241ENH: use cellPoint interpolation directly for surfaceFieldValue (#1212)20190605T14:59:10ZMark OLESENENH: use cellPoint interpolation directly for surfaceFieldValue (#1212) prior to sampledSurface supporting different interpolation schemes a
workaround means was used to simulate cellPoint > face
interpolation, with averaging of vertex interpolation.
We instead now use cellPoint interpolation direc... prior to sampledSurface supporting different interpolation schemes a
workaround means was used to simulate cellPoint > face
interpolation, with averaging of vertex interpolation.
We instead now use cellPoint interpolation directly for the face
values when 'interpolation' is on.https://develop.openfoam.com/Development/openfoam//merge_requests/240WIP: Refactor dnsFoam20191002T17:36:08ZKutalmış BerçinWIP: Refactor dnsFoam### Summary
 If applied: This commit will restructure dnsFoam in line with other
solvers, e.g. pisoFoam, without changing its external
behaviour.
 Why: Prior to this change, dnsFoam structu...### Summary
 If applied: This commit will restructure dnsFoam in line with other
solvers, e.g. pisoFoam, without changing its external
behaviour.
 Why: Prior to this change, dnsFoam structure reflected v.2.x and older
solver style.
 How: This change collects naked dnsFoam code parts under general file
structure, e.g. via UEqn.H.
### Resolved bugs (If applicable)
N/A
### Details of new models (If applicable)
N/A
### Risks
 Verification: No change in any output of dnsFoam tutorial case.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam//merge_requests/239WIP: Refactoring dnsfoam20190218T15:00:31ZKutalmış BerçinWIP: Refactoring dnsfoamUEqn.H file is created.
Its content is moved from dnsFoam.C
STYLE: Newline is removed.
ENH: Delete globalProperties.H.
Its content is appropriately moved into UEqn.H
ENH: pEqn.H is created. Its content is moved from dnsFoam.C.
ENH:...UEqn.H file is created.
Its content is moved from dnsFoam.C
STYLE: Newline is removed.
ENH: Delete globalProperties.H.
Its content is appropriately moved into UEqn.H
ENH: pEqn.H is created. Its content is moved from dnsFoam.C.
ENH: UEqn.H and pEqn.H are added.
ENH: Contents of readTurbulenceProperties.H and readTransportProperties.H are added.
ENH: Delete readTurbulenceProperties.H. Content is moved into createFields.H
ENH: Delete readTransportProperties.H Content is moved into createFields.H
ENH: Note is added for highlighting the requirement for optional FFTW lib.
ENH: Update dnsFoam.C.
Content between createFields and the first whileloop is moved into createFields.H.
ENH: Code move into createFields.H
Content between createFields and the first whileloop in dnsFoam.C is moved into createFields.H.
STYLE: Remove redundant tabs
ENH: Remove redundant tabs in UEqn.H
ENH: Add newline to UEqn.H to avoid wmkdepend warning
ENH: Add last new line into createFields.H to avoid wmkdepend warning
ENH: Add last new line into pEqn.H to avoid wmkdepend warning
ENH: include preprocessor directives are correctedMark 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/237WIP: ENH: Function Object: Lamb Vector20190213T09:09:03ZKutalmış BerçinWIP: ENH: Function Object: Lamb Vectorhttps://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/234Feature single precision20190610T14:46:52ZMattijs Janssens4Mattijs@users.noreply.develop.openfoam.comFeature single precision### Summary
Replace all linear solver (lduSolver) variables with new type 'solveScalar' instead of 'scalar'. In double precision this is the same as scalar (i.e. double), in single precision it is either double or scalar (=float).
...### Summary
Replace all linear solver (lduSolver) variables with new type 'solveScalar' instead of 'scalar'. In double precision this is the same as scalar (i.e. double), in single precision it is either double or scalar (=float).
### Resolved bugs (If applicable)
https://develop.openfoam.com/Development/OpenFOAMplus/issues/1086
### Details of new models (If applicable)
Currently: WM_PRECISION_OPTION:
 DP as usual
 SP as usual
 SPDP single precision except for linear solver, which is double precision
When using WM_SPDP argList now prints in Arch:
label=32;scalar=32;solveScalar=64
### Risks
Following tests before merging:
 DP = same performance
 SP = pure single precision same performance as current
 SPDP = mixed precision performance may need casebycase evaluationAdminAdminhttps://develop.openfoam.com/Development/openfoam//merge_requests/233WIP: Refactoring dnsfoam20190211T18:05:12ZKutalmış BerçinWIP: Refactoring dnsfoam### Summary
dnsFoam is refactored, and its external behaviour is verified through dnsFoam/boxTurb16 tutorial.
diff all the fields of {enstrophy,graphs,p,phi,U} from the original tutorial, and refactored dnsfoam yielded no change.
### ...### Summary
dnsFoam is refactored, and its external behaviour is verified through dnsFoam/boxTurb16 tutorial.
diff all the fields of {enstrophy,graphs,p,phi,U} from the original tutorial, and refactored dnsfoam yielded no change.
### Resolved bugs (If applicable)
N/A
### Details of new models (If applicable)
N/A
### Risks
N/Ahttps://develop.openfoam.com/Development/openfoam//merge_requests/232Feature object registry search20190207T08:59:08ZMark OLESENFeature object registry searchMark OLESENMark OLESEN