openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2020-07-13T17:38:14Zhttps://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/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/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/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/242Reacting heterogeneous cloud2019-05-02T18:40:27ZSergio FerrarisReacting heterogeneous cloud### Summary
New reacting heterogeneous cloud, solver and tutorial.
This cloud is formed of pure solid particles which reacts with the carrier phase.
It is derived from reacting cloud.
### Resolved bugs (If applicable)
(Links to issues...### Summary
New reacting heterogeneous cloud, solver and tutorial.
This cloud is formed of pure solid particles which reacts with the carrier phase.
It is derived from reacting cloud.
### Resolved bugs (If applicable)
(Links to issues)
### Details of new models (If applicable)
The only available reacting heterogeneous model is Heteregeneous noncatalytic reaction MUCS approach.
Reference:
D. Papanastassiou and G. Bitsianes, Modelling of Heterogeneous Gas-
Solid Reactions, Metallurgical Transsactions, 480. Volume 4. 1973
### Risks
(Possible regressions?)
(Changes to user inputs?)v1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/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).v1912https://develop.openfoam.com/Development/openfoam/-/merge_requests/99Integration foundation2017-05-22T13:06:38ZAdminIntegration foundationIntegrated Foundation developments to d2a62df:
- externalWallHeatFluxTemperature: Added optional support for radiative flux to the outside 2017-04-26.
Next Foundation commit introduced large changes to the particle tracking algorit...Integrated Foundation developments to d2a62df:
- externalWallHeatFluxTemperature: Added optional support for radiative flux to the outside 2017-04-26.
Next Foundation commit introduced large changes to the particle tracking algorithm - chosen not to include this change set until the code is more fully tested. Some additional cherry-picks have been integrated to resolve further bugs:
- a7711038d (fnd 1bb7db2b7) - CrankNicolsonDdtScheme: Corrected input of off-centering coefficient of 1 2017-05-11
- 1765b5a4a (fnd d26c6c342) - DPMDyMFoam, DPMDyMFoam: Corrected support for closed-domain simulations 2017-05-04
- 0da6a5f79 (fnd 1328b5be0) - surfaceTensionModels: Resolved warning from Clang concerning virtual function overload 2017-05-03
- 23210323e (fnd 7acfa95ea) - thermophysicalModels: Corrected alphah to be enthalpy based 2017-05-03
Main changes
- abc50e214 Updated thermo libraries to be mass based (was molar based)
- Moved edgeMesh library code inside meshTools library
- Many run-time selectable models can now use in-line dictionary input as opposed to specifying a sub <model>Coeffs dictionary
- Energy source refactored in thermo library (Sh, Qdot Qr->qr)
Other
- distributionModels - top level distributionModel class no longer in the distributionModels namespace
Deprecated
- 55f3e808e sixDoFRigidBodyDisplacementPointPatchVectorField and uncoupledSixDoFRigidBodyDisplacementPointPatchVectorField
Status:
- Tutorial Alltest loop completes except for:
- multiphase/compressibleInterDyMFoam/laminar/sphereDrop/log.compressibleInterDyMFoam: change in set-up required due to deprecation of boundary conditions
- combustion/fireFoam/LES/simplePMMApanel/log.fireFoam: reaction system problem for solid->gas reactions
Version v1706https://develop.openfoam.com/Development/openfoam/-/merge_requests/76Improvements to the conversion utilities2016-11-10T14:34:33ZMark OLESENImprovements to the conversion utilitiesVarious changes associated with issue #204.
* Reduced code duplication for handling prostar conversion and IO
* Simple conversion to/from AVL/FIRE geometries
* New library basis for conversion to/from CCM geometries - handles multiple r...Various changes associated with issue #204.
* Reduced code duplication for handling prostar conversion and IO
* Simple conversion to/from AVL/FIRE geometries
* New library basis for conversion to/from CCM geometries - handles multiple regions, conformal interfaces etc. No support for film or 2d shell geometries
* Improved infrastructure for writing VTK content. Will propagate usage through other parts of the code in the future.Version v1612Mark OLESENMark OLESENhttps://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/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/231Function object updates2019-01-31T17:00:02ZAdminFunction object updatesRenamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function ...Renamed the `residuals` function object to `solverInfo` since it now generates:
* residual fields
* solver type
* initial residual
* final residual
* number of solver iterations
* convergecnce flag
Added new `continuityError` function object. Example usage:
continuityError1
{
type continuityError;
libs ("libfieldFunctionObjects.so");
...
writeToFile yes;
log yes;
phi phi;
}
\endverbatimv1906AdminAdminhttps://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/228Feature run time control triggers2019-01-24T05:50:29ZAdminFeature run time control triggersExtends the `runTimeControl` function object to set 'trigger' values, that can be used to start other function objects. For example, to run for 100 steps after the average drag coefficient converges (reported by a `forceCoeffs` function...Extends the `runTimeControl` function object to set 'trigger' values, that can be used to start other function objects. For example, to run for 100 steps after the average drag coefficient converges (reported by a `forceCoeffs` function object) the following could be used:
```
runTimeControl1
{
type runTimeControl;
libs ("libutilityFunctionObjects.so");
conditions
{
condition1
{
type average;
functionObject forceCoeffs1;
fields (Cd);
tolerance 1e-3;
window 20;
windowType exact;
}
}
satisfiedAction setTrigger;
trigger 1;
}
runTimeControl2
{
type runTimeControl;
libs ("libutilityFunctionObjects.so");
controlMode trigger;
triggerStart 1;
conditions
{
condition1
{
type maxDuration;
duration 100;
}
}
satisfiedAction end;
}
```
See the `$FOAM_TUTORIALS/incompressible/simpleFoam/simpleCar tutorial`v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/243Feature reflective solar load2019-05-02T09:45:46ZSergio FerrarisFeature reflective solar load### Summary
Adding reflecting fluxes to Solar load radiation model.
Adding functionality to the boundary radiation models and new
place holder for basic wall types such as transparent, opaqueDiffusive,
opaqueReflective. Radiation wall ...### Summary
Adding reflecting fluxes to Solar load radiation model.
Adding functionality to the boundary radiation models and new
place holder for basic wall types such as transparent, opaqueDiffusive,
opaqueReflective. Radiation wall models are now runtime selectable.
Adding multi-band capabilities to VF model and improving the set up
for using solar loads in VF and fvDOM radiation models.
### Details of new models (If applicable)
The new entry is useReflectedRays = true in the radiationProperties.
This calculates the reflected rays on reflective walls. It can handle first reflection
on surfaces. Not multiple reflection are considered.
The wall boundary type "opaqueReflective" handles specular reflection which a proportion
of diffusive heat flux
### Risks
(Possible regressions?)
The boundaryRadiationProperties entries key words are "type", not "mode". But a backward
compatibility reading was introduced.v1906AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/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/210Feature processor level of detail (LOD)2018-06-25T07: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/301Feature particle patch postpro filtering2019-12-10T15:53:15ZAndrew HeatherFeature particle patch postpro filtering### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new mode...### Summary
Adds options to write particle-patch interactions to file, and to select particle fields to post-process for the `patchPostProcessing` cloud function object
### Resolved bugs (If applicable)
none
### Details of new models (If applicable)
Cloud patch interaction models:
Optionally write patch interaction statistics, e.g. number and mass of particles that stick, escape etc. to file using the optional `writeToFile` entry, e.g.
```
localInteractionCoeffs
{
patches
(
"(walls|cyc.*)"
{
type rebound;
}
"inlet|outlet"
{
type escape;
}
);
// New optional entry
writeToFile yes;
}
```
Cloud function objects:
New `fields` optional entry can be used to select which particle fields to post-process; if empty or the entry is not given all fields are written (to provide backwards compatibility)
```
patchPostProcessing1
{
type patchPostProcessing;
// Optional new entry
fields (position "U.*" d T nParticle);
maxStoredParcels 20;
patches
(
cycLeft_half0
cycLeft_half1
);
}
```
See the `$FOAM_TUTORIALS/lagrangian/reactingParcelFilm/filter` tutorial for an example
### Risks
Low riskv1912Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/272Feature mixed precision2019-08-13T11:07:08ZMark OLESENFeature mixed precisionThis set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_L...This set of changes makes it easier to identify and manage binary reading from different representations. For example, a binary file written from an OpenFOAM installation with WM_SP, WM_LABEL_SIZE=32 can be read back as WM_DP and/or WM_LABEL_SIZE=64. This is managed internally by using the "arch" information that is included in the binary output files. For example,
```
FoamFile
{
version 2.0;
format binary;
class vectorField;
arch "LSB;label=32;scalar=64";
location "constant/polyMesh";
object points;
}
```
On reading, the size information is used to determine if the label/scalar sizes in the file correspond to the *native* version of the currently active OpenFOAM installation. If the values are identical, the binary file reading is as always. If, however, there is a discrepancy between the label/scalar sizes in the file and the current OpenFOAM sizes, the values will be read in the raw format and converted on-the-fly. This adds no additional memory overhead, but can potentially result in somewhat lower reading speeds. There are some additional operations when narrowing the representation (eg, reading in double but saving as float) to avoid underflow and overflow, but it cannot work magic. If your input file has 1e10 faces, the addressing will not fit into a signed or unsigned 32-bit integer.
To manage the reading, the new trait structures `is_contiguous`, `is_contiguous_label`, `is_contiguous_scalar` are used. For data payloads that comprise homogenous base types (ie, the lowest level component is entirely scalar or label) the Detail::readContiguous is used for managing the reading in a uniform manner. For heterogeneous data types, the author of the class must address this individually. This is typically in the following form:
```
if (is.format() == IOstream::ASCII)
{
is >> start_ >> end_ >> level_ >> i_ >> j_ >> k_;
}
else if (!is.checkLabelSize<>() || !is.checkScalarSize<>())
{
// Non-native label or scalar size
is.beginRawRead();
readRawScalar(is, start_.data(), vector::nComponents);
readRawScalar(is, end_.data(), vector::nComponents);
readRawLabel(is, &level_);
readRawLabel(is, &i_);
readRawLabel(is, &j_);
readRawLabel(is, &k_);
is.endRawRead();
}
else
{
is.read
(
reinterpret_cast<char*>(&start_),
sizeofFields_
);
}
```
### Limitation
Changes in the endian type are not handled.v1912AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/306Feature mesh update controls2019-12-12T11:03:03ZAndrew HeatherFeature mesh update controls### Summary
Adds a new update function to `dynamicFvMesh` that enables users to control how often the mesh is updated for moving mesh cases.
### Details of new models (If applicable)
Adds a `timeControl` object to `dynamicFvMesh`, i....### Summary
Adds a new update function to `dynamicFvMesh` that enables users to control how often the mesh is updated for moving mesh cases.
### Details of new models (If applicable)
Adds a `timeControl` object to `dynamicFvMesh`, i.e. the same controls as used by function objects. This requires the top-level solver to call the new
mesh.controlledUpdate();
function instead of
mesh.update();
Currently applied to `pimpleFoam` and `rhoPimpleFoam` only for beta testing, and likely to be rolled out across other solvers in future releases.
Example usage in the `dynamicMeshDict`
updateControl timeStep;
updateInterval 5;
### Risks
Only applied to the solvers mentioned above (for now) - testing has not shown any regressions.v1912Mark OLESENMark OLESEN