openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2023-12-04T12:32:19Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/644Added Abaqus sampling and writing2023-12-04T12:32:19ZAndrew HeatherAdded Abaqus sampling and writingAdds:
- Abaqus mesh `sampledSet` : `abaqusMesh`
- Abaqus co-ord set writer : `abaqus`
- Added field level/scale from surface writers to co-ord writersAdds:
- Abaqus mesh `sampledSet` : `abaqusMesh`
- Abaqus co-ord set writer : `abaqus`
- Added field level/scale from surface writers to co-ord writersv2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/646Extract case and solver information2023-12-04T09:51:36ZAndrew HeatherExtract case and solver informationSeries of changes to support extraction of case/solver information in OpenFOAM dictionary/JSON formats.
- ENH: checkMesh - added -writeChecks option
- TUT: Added caseInfo function object example
- ENH: Added new caseInfo function object...Series of changes to support extraction of case/solver information in OpenFOAM dictionary/JSON formats.
- ENH: checkMesh - added -writeChecks option
- TUT: Added caseInfo function object example
- ENH: Added new caseInfo function object
- ENH: Added new JSONformatter to write Ostream content in JSON format
- ENH: polyMeshCheck - added mesh quality metrics to meshState dictionary
- STYLE: Refactoring use of meshState in {fv|faMesh}
- STYLE: renamed/moved 'data' to 'meshState'v2312Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/555overset modifications: allow overset pacthes overlap, allow fringe faces walk...2022-11-14T15:49:00ZSergio Ferrarisoverset 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 U-p 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 pre-condition 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.v2212Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/551Update of view factor generation using 2AI and 2LI methods plus CGAL for ray ...2022-08-12T08:53:39ZSergio FerrarisUpdate of view factor generation using 2AI and 2LI methods plus CGAL for ray tracing### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
...### Summary
This view factors generation application uses a combined approach of
double area integral (2AI) and double linear integral (2LI). 2AI is used
when the two surfaces are 'far' apart and 2LI when they are 'close'.
The distance between faces is calculating a ratio between averaged areas and the distance between face
centres. 2LI is integrated along edges using Gaussian quadrature with a given tolerance.
This approach doesn't use face agglomeration as pre-processing step.
Optional new feature can be used to solve the system of equations from the s2s system using the
standard iterative linear solvers in OpenFOAM.
### Resolved bugs
The old method used 2AI and agglomeration for all the view fators. The 2AI is not accurate for faces which
are in close proximity. The agglomeration process proved to be problematic concerning the face centre and normal calculation.
### Details of new models
The extra inputs in the s2s dictionary are:
GaussQuadTol 0.1; // GaussQuad integral error tolerance (default : 0.01). Used to decide when to increase order of integration.
distTol 8; // relative distance (default : 8). For <distTol : use 2LI, >distTol : use 2AI
alpha 0.22; // Constant model use for common edges for 2LI (default : 0.22). Approx for integral value of duplicate edges.
intTol 1e-2; // (m) Interval tolerance. This is used for ray shooting from
// face centre to face centre plus `intTol` in order to avoid the ray to hit the same face where it was originated. (default : 1e-2)
The default values are generally reasonable for a wide range of cases.
The optional iterative linear solver is specified in the radiationProperty dictionary:
```
viewFactorCoeffs
{
smoothing false; // Use for closed surfaces where sum(Fij) = 1
constantEmissivity true;
nBands 1;
useDirectSolver false; // Use direct solver on master or fully parallel iterative solver
}
```
NOTE: In this development face agglomeration is not needed. The model will create an identity list if it is not present. Thus, it is not necessary for the user to run `faceAgglomerate`. But, the framework for using faceagglomeration was left inside the model as it can be needed in later stages.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/542General enhancement to icoReactingMultiphaseInterFoam solver, sub-models and ...2022-06-22T09:18:53ZSergio FerrarisGeneral enhancement to icoReactingMultiphaseInterFoam solver, sub-models and FO's1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models i...1) Name changing and namespace used for some multi phase class used in icoReactingMultiphaseInterFoam.
2) Creating a new derivedFvPatch for thermal BC's (detached from TurbulenceCompressible) which allows to
use phase system models in FO's. This new lib was added to all the thermal solvers
3) Adding new diffusion-based mass transfer model to icoReactingMultiphaseInterFoam
4) Improving consistency of Hf between phases (updated tutorials entries)
5) HeatFlux and htc FO's are available to use with icoReactingMultiphaseInterFoam
NOTE: There is memory leak problem at the end of the run when using icoReactingMultiphaseInterFoam and 'fieldFunctionObjects' is loaded usng lddOpen. NEED TO BE REVIEWEDv2206Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/550s2s linear system solution using lduMatrix2022-06-15T12:26:28ZSergio Ferrariss2s linear system solution using lduMatrix s2s linear system solution using lduMatrix for qr s2s linear system solution using lduMatrix for qrv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/548species and heat adsorption BC's and fvOption source2022-06-14T11:28:42ZSergio Ferrarisspecies and heat adsorption BC's and fvOption sourceImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesImplementation of species and heat adsorption BC's.
Implementation of a fvOption source on cells attached to patchesv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/543Adding external heat to greyDiffusive BC and new Doses FO2022-05-27T09:15:36ZSergio FerrarisAdding external heat to greyDiffusive BC and new Doses FO### Summary
Adding Lagrangian dose function object. Additional external radiative heat flux to ray greyDiffusive BC for fvDOM
### Details of new models (If applicable)
qRadExt and qRadExtDir new optional entries to specified heat flu...### Summary
Adding Lagrangian dose function object. Additional external radiative heat flux to ray greyDiffusive BC for fvDOM
### Details of new models (If applicable)
qRadExt and qRadExtDir new optional entries to specified heat flux. This is added to the closest ray direction.
If qRadExtDir is not specified the heat flux is add normal to the face.
### Risks
Minimalv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/509Additional sub-cooling heat transfer correlations for liquid H22021-12-15T10:16:50ZSergio FerrarisAdditional sub-cooling heat transfer correlations for liquid H21) Adding basic thermodynamic functions for rho and Cp at (T,p)
2) Adding heat transfer correlations for boiling film, transient and sub-cooling boiling regimes for liquid-H2.
3) Option to use a correlation-type of HTC for sub-cooling re...1) Adding basic thermodynamic functions for rho and Cp at (T,p)
2) Adding heat transfer correlations for boiling film, transient and sub-cooling boiling regimes for liquid-H2.
3) Option to use a correlation-type of HTC for sub-cooling regime instead of the standard RTI model.
4) Minor fix to the thermo for h-Polynomial type.v2112Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/510ENH: interfaceOxideRate: new mass transfer model for icoReactingMultiphaseInt...2021-12-09T17:05:24ZSergio FerrarisENH: interfaceOxideRate: new mass transfer model for icoReactingMultiphaseInterFoam solver- Adding new mass transfer model based on:
Cao, L., Sun, F., Chen, T., Tang, Y., & Liao, D. (2018).
Quantitative prediction of oxide inclusion defects inside
the casting and on the walls during cast-f...- Adding new mass transfer model based on:
Cao, L., Sun, F., Chen, T., Tang, Y., & Liao, D. (2018).
Quantitative prediction of oxide inclusion defects inside
the casting and on the walls during cast-filling processes.
International Journal of Heat and Mass Transfer, 119, 614-623.
DOI:10.1016/j.ijheatmasstransfer.2017.11.127
The model calculates the oxide produced at the air-liquid interface of a VOF system.
- A new BC was created to quantify the amount of oxide mass absorbed by walls.v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/508ENH: New liquid film features2021-12-09T17:02:19ZSergio FerrarisENH: New liquid film featuresAdding addition wall-function shear stress model to the film friction at the gas interface.
Updating tutorials accordinglyAdding addition wall-function shear stress model to the film friction at the gas interface.
Updating tutorials accordinglyv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/496ENH: New suite for electrostatic deposition applications2021-11-24T18:06:40ZKutalmış BerçinENH: New suite for electrostatic deposition applications### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-...### Summary
- New suite for electrostatic deposition applications
- Solver function object: `electricPotential`: Computes the steady-state equation of charge conservation to obtain the electric potential by strictly assuming a quasi-static electrostatic field for single-phase and multiphase applications.
- Finite-volume boundary condition: `electrostaticDeposition`: A boundary condition to calculate electric potential (`V`) on a given boundary based on film thickness (`h`) and film resistance (`R`) fields which are updated based on a given patch-normal current density field (`jn`), Coulombic efficiency and film resistivity.
- Allowing to set:
- Minimum current density for deposition onset
- Minimum accumulative specific charge for deposition onset
- Resistance due to main body and/or pretreatment layers
- Initial electric potential
### Resolved bugs
N/A
### Details of new models (If applicable)
A showcase illustrating the verification of the `electricPotential` function object. Right: dielectric-dielectric water-air; left: conductive-dielectric water-air mixture ([López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)).
![image](/uploads/fd8508ee81de44186bcc26d60eebc0f3/image.png)
A showcase illustrating the `electrostaticDeposition` BC: pending
### Risks
- No changes in existing output.
### Constraints
- Depletion or abrasion of material due to negative current is not allowed.
- Boundary-condition updates are not allowed during outer corrections to prevent spurious accumulation of film thickness.
- `resistivity`, `jMin`, `qMin` and `Rbody` are always non-negative.
- Quasi steady
- No electrolyte/ionic transport
- Quiescent
- Sufficiently mixed
- No magnetic field
- No electrolyte and electric field interaction
- Isotropic material and electrolyte
- No film-flow interactions
- No finite-area numerics
### Remaining issues
- Micro/nano current densities/potential differences cause numerical instabilities.
- Small diffs in patch-normal current-density values of cathode faces can lead to small diffs in incremental film thickness (Delta_h) on those faces. With the very high value of 'resistivity', the small diffs in 'Delta_h' can then lead to comparable diffs in incremental electric potential differences across patch faces.
- These differences can then be accumulated throughout a simulation, causing non-zero potential difference gradients across faces of the cathode.
- Our workaround was to round the floating-point numbers of operand variables to a given number of decimal points (default: 8 decimals) - disallow micro/nano volts, so that such accumulation could be avoided.
- However, this issue may cause numerical instabilities in more complex cases.
- Therefore, the original expressions of the formulation may need to be revisited.
- Advanced electrodeposition applications using OpenFOAM can be visited as well:
- [Kauffman et al., 2020](https://doi.org/10.3390/fluids5040240)
- [López-Herrera et al., 2011](https://www.doi.org/10.1016/j.jcp.2010.11.042)
- [Roghair et al., 2013](https://ris.utwente.nl/ws/portalfiles/portal/5676495/Roghair+Paper_final_draft_v1.pdf)
- Takayama et al., 2013, Implementation of a Model for Electroplating in
OpenFOAM.
- [Kashir et al., 2019](https://www.doi.org/10.1063/1.5050793)
- [EHDIonFOAM](https://openfoamwiki.net/index.php/Extend-bazaar/solvers/multiphase/EHDIonFOAM)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/477Implicit treatment of coupled boundary conditions2021-08-03T20:08:53ZSergio FerrarisImplicit treatment of coupled boundary conditions## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit ar...## Summary
The alternative addressing insert new internal faces on selected coupled patches. Extending the matrix addressing allows the implicit treatment of some boundary conditions. At the moment, the BCs which can be made implicit are: cyclic, AMI, ACMI and mapped.
The entry `useImplicit true` is needed in the field BC. Only scalar fields can be made implicit (p, p_rgh, k, epsilon, etc). The U field **cannot** be implicit.
The top solvers are unchanged except for the cht solvers where a single he matrix is built for the multi-region case.
In the case that more than one patch is present, the user can choose which ones are treated implicitly, i.e **p** can be implicit in AMI1 and explicit in AMI2 and **k** the other way around.
Currently, there exists a limitation for parallel cases where AMI patch-pairs need to be on the same processor. For cyclics and mapped patches, the number of faces on each processor **MUST** be the same. Therefore a constraint decomposition needs to be used.
## Details of new models
The model adds a new numbering of internal/boundary coefficients and patch ID's. This is constructed at the call of the matrix.solve() - it is reset to the original addressing after solving.
The original internal/boundary coeffs are cached and used (in some cases with some extra information) to fill the coefficients on the new internal faces and/or source term on the newly formed fvMatrix.
## Tutorials
- tutorials/heatTransfer/chtMultiRegionSimpleFoam/cpuCabinet/
- tutorials/heatTransfer/chtMultiRegionFoam/snappyMultiRegionHeaterImplicit/
- tutorials/basic/laplacianFoam/implicitAMI/
- tutorials/basic/simpleFoam/implicitAMI
- tutorials/basic/chtMultiRegionFoam/2DImplicitCyclic/
## Risks
Addressing of cells on the patches are changed, this needs to be passed to all the lduInterfaces. Use alternative lduAddressing in lduMatrix.
The coupled BCs (cyclics, AMI, mapped) which made implicit don't exist at the moment of solving the matrix. Thus, any fvOption or FO referring to this BC will **Fail**
In general terms when using the implicit approach the lduaddressing changes and therefore any matrix solve will be affected in _all top level solvers and all the linear solvers_.v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/475finiteArea: new models and solvers for films2021-07-16T16:39:50ZSergio FerrarisfiniteArea: new models and solvers for films- Adding `kinematicParcelFoam` solver:
- The original `thermoSurfaceFilm` sub-models were divided between `kinematicSurfaceFilm` and `thermoSurfaceFilm` in order to use the `surfaceFilm` model in a `kinematicCloud`.
- The film in...- Adding `kinematicParcelFoam` solver:
- The original `thermoSurfaceFilm` sub-models were divided between `kinematicSurfaceFilm` and `thermoSurfaceFilm` in order to use the `surfaceFilm` model in a `kinematicCloud`.
- The film interaction models are now in a `kinematicSurface` class which can be used in a kinematic cloud adding constant thermal properties (`p` and `T`) for some sub-models, e.g. `drySplashInteraction`, `wetSplashInteraction` etc.
- `pRef` and `Tref` were added to the `kinematicSurfaceFilm` as entry to the `regionFilm` when used with a kinematic cloud.
- In the finite area surface film model `Tref`, `pRef` are stored in `filmSubModel`.
- Film models:
- Only laminar turbulence is available for wall friction and gas shear stress. Wall friction models:
- quadraticProfile,
- linearProfile,
- DarcyWeisbach,
- ManningStrickle
- gas friction models: `Cf *(Ufilm - Ufluid)`. This would need to be improved using turbulent shear stress from the flow.
- `curvatureSepration` injection model from the film to Lagrangian particles
- minimum (`fThreshold`) force and minimum curvature (`minInvR1`) for separation were added to have more control on determining the points of film separation.
- To force wall-like BC from the fluid side the option `zeroWallVelocity true;`. Allows the film to be seen as zero U BC by the flow.
- forces: The only available extra forces (apart from gravity) is contact angle force: `perturbedTemperatureDependentContactAngle`v2112Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/463ENH: Adding subMesh option to momentumError and div FOs2021-07-03T19:59:35ZSergio FerrarisENH: Adding subMesh option to momentumError and div FOs- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Op...- Adding subMesh capabilities to momentumError and div FOs.
- A subMesh is created from cellZones to compute FOs.
- The operators (div, etc) are only calculated in the subMesh.
- Zero field is written in the non-subMesh cells.
- Optionally, halo cells can be added to the cellZones.
- New helper class to handle the subMesh creation and field mapping.
- TUT: add an example to `tutorials/compressible/rhoSimpleFoam/aerofoilNACA0012`v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/397ENH: buoyantTurbSource: new fvOption2020-12-08T16:54:52ZKutalmış BerçinENH: buoyantTurbSource: new fvOptionAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/396Feature recycle particles2020-12-07T09:37:33ZAndrew HeatherFeature recycle particles### Summary
Added a new `recycleInteraction` lagrangian `patchInteractionModel`. This can be used to recycle/re-inject particles that would otherwise exit the domain.
### Details of new models (If applicable)
Example input in the `<...### Summary
Added a new `recycleInteraction` lagrangian `patchInteractionModel`. This can be used to recycle/re-inject particles that would otherwise exit the domain.
### Details of new models (If applicable)
Example input in the `<constant>/reactingCloud1Properties` file:
```
multiInteractionCoeffs
{
oneInteractionOnly no;
model2
{
patchInteractionModel recycleInteraction;
recycleInteractionCoeffs
{
recyclePatches ((outlet inlet2));
recycleFraction 0.8;
}
}
model1
{
patchInteractionModel standardWallInteraction;
standardWallInteractionCoeffs
{
type rebound;
}
writeToFile yes;
}
}
```
Here the `multiInteraction` model serves as a wrapper, whereby the a `standardWallInteraction` model is used for particle/wall interactions and the new `recycleInteraction` model to reinject particles that exit via the `outlet` patch back into the domain via `inlet2`.
When recycling the particles, the `recycleFraction` entry can be used to retain a certain amount of mass. In the example above, 80% of the mass of particles is reintroduced.
Example case: `$FOAM_SRC/lagrangian/reactingParcelFoam/recycleParticles`
### Risks
Low risk - modular extensionv2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/244WIP: Feature euler euler solvers. Integration of Euler solvers.2020-07-13T17: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, sub-models, 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/323WIP: ENH: add 'outputCoeffs' and 'extendedOutput' options to forceCoeffs2020-01-17T21:07:23ZKutalmış BerçinWIP: ENH: add 'outputCoeffs' and 'extendedOutput' options to forceCoeffsENH: add 'extendedOutput' option that allows to output all constitutents
of all force coefficients, i.e. total, pressure, viscous, and porous
ENH: add 'outputCoeffs' option to allow to select coefficients to output
...ENH: add 'extendedOutput' option that allows to output all constitutents
of all force coefficients, i.e. total, pressure, viscous, and porous
ENH: add 'outputCoeffs' option to allow to select coefficients to output
ENH: remove redundant computations for porosity constituent when the option
porosity=false
DOC: improve header file and function declaration docs
BAKW: test backward compatibility and functionality in comparison to
v1906 by using `simpleFoam/motorBike` and `simpleFoam/bump2D`.
Tests have involved:
- Serial runs
- Parallel runs
- Serial restart
- Parallel restart
- Only binData = on (parallel)
- Only writeFields = on (parallel)
- Only extendedOutput = on (parallel)
- binData and extendedOutput = on (parallel)
- writeFields and extendedOutput = on (parallel)
- outputCoeffs and extendedOutput = on for arbitrarily chosen
(Cd CmRoll Cl) (parallel and serial)v2006Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/316New VOF multiphaseStabilizedTurbulence fvOption2019-12-19T08:46:51ZAndrew HeatherNew VOF multiphaseStabilizedTurbulence fvOption### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase i...### Summary
Applies corrections to turbulence kinetic energy equation and turbulence viscosity field for incompressible multiphase flow cases.
Turbulence kinetic energy is over-predicted in incompressible VOF solvers at the phase interface and throughout the water column in nearly-potential flow regions beneath surface waves.
This fvOption applies corrections based on the references:
Buoyancy source term in turbulence kinetic energy equation:
Devolder, B., Rauwoens, P., and Troch, P. (2017).
Application of a buoyancy-modified k-w SST turbulence model to
simulate wave run-up around a monopile subjected to regular waves
using OpenFOAM.
Coastal Engineering, 125, 81-94.
Correction to turbulence viscosity:
Larsen, B.E. and Fuhrman, D.R. (2018).
On the over-production of turbulence beneath surface waves in
Reynolds-averaged Navier-Stokes models
J. Fluid Mech, 853, 419-460
### Resolved bugs (If applicable)
See #1433
### Details of new models (If applicable)
The implementation is based on the form for the k-epsilon turbulence model.
Example usage:
multiphaseStabilizedTurbulence1
{
type multiphaseStabilizedTurbulence;
active yes;
multiphaseStabilizedTurbulenceCoeffs
{
// Optional coefficients
lambda2 0.1; // A value of 0 sets the nut correction to 0
Cmu 0.09; // from k-epsilon model
C 1.51; // model coefficient from k-omega model
alpha 1.36; // 1/Prt
}
}
The model `C` coefficient for the k-epsilon model equates to C2/C1 = 1.33; the (default) value of 1.51 comes from the k-omega model and is more conservative.
### Risks
Modular - low risk
### Credits
Thanks go to the Turbulence Technical Committee, and the useful discussions with and code testing by Bjarke Eltard-Larsen and David Fuhrman (Technical University of Denmark).v1912