openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2022-04-29T20:00:23Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/531ENH: outletMappedUniformInlet: add multiple fraction, offset and time delays2022-04-29T20:00:23ZKutalmış BerçinENH: outletMappedUniformInlet: add multiple fraction, offset and time delays### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for eac...### Summary
**Aim**
To implement a recirculation boundary
condition for an arbitrary operand scalar with:
- Multiple connected outlets and inlets
- Optional filtration fraction for each recirculation
loop
- Optional time delay for each recirculation loop
Additionally, write-control of `scalarTransport` was transferred from `controlDict` to the function object, and enabled `UList` parameters in `interpolateXY` for wider applications.
**Previous status**
Existing boundary condition: `outletMappedUniformInlet`
- Connected between a single outlet and a single inlet
- Instantaneous recirculation: no outlet-to-inlet time delay
- Optional filtration fraction is available as a constant value
- Optional offset is available as a constant value
**Improvements**
- Arbitrary number of outlets can be connected to a single inlet
- Each inlet can be connected to different and arbitrary
combination of outlets
- Each outlet-inlet connection has:
- Optional filtration fraction as a Function1 type
- Optional offset as a Function1 type (i.e. adding/substracting a substance)
- Optional time delay (from outlet to inlet) as a Function1 type
- Each inlet has an optional base inlet-field as a PatchFunction1 type
**Theory**
<img src="/uploads/5cd45d1e0a12a12011aa090361fa16ba/image.png" width="50%" height="50%" />
**Usage**
<img src="/uploads/d6b9aa06465e479f2fcbae6ea92f84e2/image.png" width="75%" height="75%" />
### Resolved bugs
N/A
### Methodology
**Remarks**
- Difficult to design a simple verification test case due to the amount of data
- Verifications were carried out heuristically and manually
- No validation/benchmark available
**Tests**
- Cases
- Single-outlet single-inlet, pisoFoam-LES, constant time-step: [1-single-outlet-inlet.zip](/uploads/bfe8ee7572c24cde5ccd4cb555d9b9d3/1-single-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, pisoFoam-LES, constant time-step: [2-multiple-outlet-inlet.zip](/uploads/dd2b892e86e2b39f829f6189a060b23b/2-multiple-outlet-inlet.zip)
- Multiple-outlet multiple-inlet, reactingParcelFoam-RANS, adjustable time-step
- Scenarios
- Single/multiple-processor run
- Single/multiple-processor run with restart
- decomposePar
- reconstructPar
- redistributePar –decompose
-redistributePar -reconstruct
- No collated-format tests
- Only scalar fields
### Discussion
- No inlet-inlet connection
- Could not infer any necessity for an inlet-inlet
connection. Happy to be proven incorrect, however.
- No constraints were put onto the input entries;
therefore, users need to use their attention
and engineering judgements to avoid
potential unphysical results
- Except negative input of time delays are
suppresed to be zero without emitting any
warning messages.
- For example, filtration fraction can be set to
any number (e.g. more than 100%)
- Needs extensive tests to assume the
functionalities safe for any single-phase,
multiphase and overset finite-volume
applications.
### Meta-data
EP#1730
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/530BUG: 2022-1: Various bug fixes2022-05-06T10:03:56ZKutalmış BerçinBUG: 2022-1: Various bug fixes### Resolved bugs
#2299
#2312
#2337
#2429
#2343
#2360
#2426
#2422
#2428
#2425
#2419
#1967
#2391
### Risks
* Expected changes in output
* No changes in mandatory user input.
### Tests
* [x] Clean compilation (incl. submodules):
*...### Resolved bugs
#2299
#2312
#2337
#2429
#2343
#2360
#2426
#2422
#2428
#2425
#2419
#1967
#2391
### Risks
* Expected changes in output
* No changes in mandatory user input.
### Tests
* [x] Clean compilation (incl. submodules):
* [x] `linux64ClangDPInt32Opt` (clang11)
* [x] `linux64GccDPInt32Opt`
* [x] `linux64GccSPDPInt64Debug`
* [x] Alltest: No new errorAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/529dynamic mesh (un)refinement: compatible with mesh motion2022-03-07T16:07:20ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdynamic mesh (un)refinement: compatible with mesh motion### Summary
See #2395### Summary
See #2395Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/528Pstream performance and handling improvements2022-07-08T10:40:49ZMark OLESENPstream performance and handling improvements- MPI intrinsics for common primitive types (#2351)
- new broadcast Pstream for one-to-all communications (RIST #2371)
- wrap MPI broadcast for OpenFOAM _scatter_ operations
- improved globalIndex handling
- isoAdvection communication im...- MPI intrinsics for common primitive types (#2351)
- new broadcast Pstream for one-to-all communications (RIST #2371)
- wrap MPI broadcast for OpenFOAM _scatter_ operations
- improved globalIndex handling
- isoAdvection communication improvementsv2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/527ENH: cyclicAMI: extend faceAreaWeight to filter. See #23782022-02-24T11:56:54ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: cyclicAMI: extend faceAreaWeight to filter. See #2378### Summary
See #2378.
Attached is a hack of tutorials/basic/laplacianFoam/implicitAMI with the two blocks separated slightly and the AMI changed into an ACMI. In the blockMeshDict the search-distance is tuned to find only overlaps whe...### Summary
See #2378.
Attached is a hack of tutorials/basic/laplacianFoam/implicitAMI with the two blocks separated slightly and the AMI changed into an ACMI. In the blockMeshDict the search-distance is tuned to find only overlaps where the faces are close together (closer than 5e-3):
```
AMI1
{
type cyclicACMI;
maxDistance2 25e-6;
neighbourPatch AMI2;
transform noOrdering;
nonOverlapPatch AMI1_blockage;
..
}
```
Running `checkMesh -allGeometry` will write postProcessing `mask` file showing that the overlap is 100% where the faces are close and 0 where they are further away.
![mask_with_5e-3](/uploads/310fe2f0f6c05540232e63e352951abd/mask_with_5e-3.png)]Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/525Draft: Extend splitMeshRegions to automatically create AMI inter-region patches2022-02-17T12:01:17ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comDraft: Extend splitMeshRegions to automatically create AMI inter-region patches### Summary
splitMeshRegions by default creates one-to-one 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 one-to-one 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 inter-region 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/524refactor coordSet writers (#2347)2022-04-12T14:54:13ZMark OLESENrefactor coordSet writers (#2347)### Summary
Replace old, stateless, templated _writer_ class with a _coordSetWriter_ class that more closely resembles _surfaceWriter_. It is time-aware and can be used as a streamer with sample/write of each field instead of accumulati...### Summary
Replace old, stateless, templated _writer_ class with a _coordSetWriter_ class that more closely resembles _surfaceWriter_. It is time-aware and can be used as a streamer with sample/write of each field instead of accumulating all of the sampled fields ahead of time.v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/523ENH: runTimeControl - enable resetting the trigger to an earlier instant2022-02-28T07:07:47ZAndrew HeatherENH: runTimeControl - enable resetting the trigger to an earlier instantThe runTimeControl function object can activate further function objects using
triggers. Previously the trigger index could only advance; this change set
allows users to set smaller values to enable function object recycling, e.g.
Repea...The runTimeControl function object can activate further function objects using
triggers. Previously the trigger index could only advance; this change set
allows users to set smaller values to enable function object recycling, e.g.
Repeat for N cycles:
1. average the pressure at a point in space
2. when the average stabilises, run for a further 100 iterations
3. set a new patch inlet velocity
- back to (1)
Added a 'none' condition that acts as a pass-through/no-op with the option to
set a new trigger value.
Refactored the averageCondition run-time condition and valueAverage FO to use
a common basev2206Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/522bugfixes and style changes2022-02-01T10:18:22ZMark OLESENbugfixes and style changes- bug and consistency fixes for linked-lists
- overhead reduction for wordRe- bug and consistency fixes for linked-lists
- overhead reduction for wordReAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/521Lagrangian modelling updates/new features2021-12-15T10:46:58ZAndrew HeatherLagrangian modelling updates/new featuresMultiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject...Multiple enhancements:
- `PatchInjectionModel`: updated to include additional velocity specification options
- `ConeNozzleInjection`: updated to enable dynamic position and direction vectors
- `FaceInteraction`: new `cloudFunctionObject`
## PatchInjectionModel
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 1e-3;
variance 1e-4;
minValue 1e-5;
maxValue 2e-3;
}
}
}
```
See the new $FOAM_TUTORIALS/lagrangian/kinematicParcelFoam/spinningDisk tutorial
## ConeNozzleInjection
- Now only has the options `point` and `disk` (deprecated `movingPoint`)
- moving state is based on the type of `Function1`
- The position and direction entries are `Function1`-types, e.g. for the `table` type the entries could be:
```
position table
(
( 0 (0.1 0.5 0.5))
(0.2 (0.5 0.9 0.5))
(0.4 (0.9 0.5 0.5))
(0.6 (0.5 0.1 0.5))
(0.8 (0.5 0.5 0.9))
(1.0 (0.5 0.9 0.5))
(1.2 (0.5 0.5 0.1))
(1.4 (0.5 0.1 0.5))
);
direction table
(
( 0 ( 1 0 0))
(0.2 ( 0 -1 0))
(0.4 (-1 0 0))
(0.6 ( 0 1 0))
(0.8 ( 0 0 -1))
(1.0 ( 0 -1 0))
(1.2 ( 0 0 1))
(1.4 ( 0 1 0))
);
```
## FaceInteraction
Enables particles to interact with mesh faces (described using `faceZones`).
```
faceInteraction1
{
type faceInteraction;
faceZones
(
(blockageFaces stick)
// (blockageFaces escape)
// (blockageFaces rebound) // not applicable for this test case (!)
);
dMin 0;
dMax 1;
}
The `faceZones` entry is a list of (`faceZoneName` `interactionType`), where interaction type is either `stick`, `escape` or `rebound`.
No tutorial added yet; for testing: reactingParcelFoam case: [filter.tgz](/uploads/e0034538f6c9bb85c0cfa3e1068a6ba2/filter.tgz)v2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/520ENH: rigidBodyMotion: new Function1-type accelerationRelaxation2021-12-15T10:17:12ZKutalmış BerçinENH: rigidBodyMotion: new Function1-type accelerationRelaxationTUT: floatingObject: add Function1-type accelerationRelaxation exampleTUT: floatingObject: add Function1-type accelerationRelaxation examplev2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/519Added new propellerInfo function object2021-12-14T16:45:32ZAndrew HeatherAdded new propellerInfo function object## Calculates propeller performance and wake field properties.
Controlled by executeControl:
- Propeller performance
- Thrust coefficient, Kt
- Torque coefficient, 10*Kq
- Advance coefficient, J
- Open water efficiency, etaO
-...## Calculates propeller performance and wake field properties.
Controlled by executeControl:
- Propeller performance
- Thrust coefficient, Kt
- Torque coefficient, 10*Kq
- Advance coefficient, J
- Open water efficiency, etaO
- Written to postProcessing/<name>/<time>/propellerPerformance.dat
Controlled by writeControl:
- Wake field text file
- Wake: 1 - UzMean/URef
- Velocity in cylindrical coordinates at xyz locations
- Written to postProcessing/<name>/<time>/wake.dat
- Axial wake field text file
- 1 - Uz/URef at r/R and angle
- Written to postProcessing/<name>/<time>/axialWake.dat
- Velocity surface
- Written to postProcessing/<name>/surfaces/time>/disk.<fileType>
Example wake field - Courtesy of Yannick Eberhard, Promarin GmbH
![v2112-postProcessing-propellerInfo](/uploads/77553caacb0835eb100773b7b10bfbb7/v2112-postProcessing-propellerInfo.png)
## Usage
Example of function object specification:
```
propellerInfo1
{
type propellerInfo;
libs (forces);
writeControl writeTime;
patches ("propeller.*");
URef 5; // Function1 type; 'constant' form shown here
rho rhoInf; // incompressible
rhoInf 1.2;
// Optionally write propeller performance data
writePropellerPerformance yes;
// Propeller data:
// Radius
radius 0.1;
rotationMode specified; // specified | MRF
// rotationMode = specified:
origin (0 -0.1 0);
n 25.15;
axis (0 1 0);
// Optional reference direction for angle (alpha) = 0
alphaAxis (1 0 0);
//// rotationMode = mrf
//// MRF MRFZoneName;
//// (origin, n and axis retrieved from MRF model)
// Optionally write wake text files
// Note: controlled by writeControl
writeWakeFields yes;
// Sample plane (disk) properties
// Note: controlled by writeControl
sampleDisk
{
surfaceWriter vtk;
r1 0.05;
r2 0.2;
nTheta 36;
nRadial 10;
interpolationScheme cellPoint;
errorOnPointNotFound false;
}
}
```
Where the entries comprise:
| Property | Description | Required | Deflt value |
| ------ | ------ |--|-- |
| type | Type name: propellerInfo | yes | |
| log | Write to standard output | no | no |
| patches | Patches included in the forces calculation | yes |
| p | Pressure field name | no | p |
| U | Velocity field name | no | U |
| rho | Density field name | no | rho |
| URef | Reference velocity | yes | |
| rotationMode | Rotation mode (see below) | yes | |
| origin | Sample disk centre | no* | |
| n | Revolutions per second | no* | |
| axis | Propeller axis | no* | |
| alphaAxis | Axis that defines alpha=0 dir | no | |
| MRF | Name of MRF zone | no* | |
| originOffset | Origin offset for MRF mode | no | (0 0 0) |
| writePropellerPerformance| Write propeller performance text file | yes | |
| writeWakeFields | Write wake field text files | yes | |
| surfaceWriter | Sample disk surface writer | no* | |
| r1 | Sample disk inner radius | no | 0 |
| r2 | Sample disk outer radius | no* | |
| nTheta | Divisions in theta direction | no* | |
| nRadial | Divisions in radial direction | no* | |
| interpolationScheme | Sampling interpolation scheme | no* | cell |
Note
- `URef` is a scalar `Function1` type, i.e. supports `constant`, `table`, lookup values
- `rotationMode` is used to set the origin, axis and revolutions per second
- if set to `specified` all 3 entries are required
- note: `origin` is the sample disk origin
- if set to `MRF` only the MRF entry is required
- to move the sample disk away from the MRF origin, use the `originOffset`
- if `writePropellerPerformance` is set to on|true:
- `propellerPerformance` text file will be written
- if `writeWakeFields` is set to on|true:
- wake and `axialWake` text files will be written
- if the `surfaceWriter` entry is set, the sample disk surface will be written
- extents set according to the `r1` and `r2` entries
- discretised according to the `nTheta` and `nRadial` entries
Note: sign-off in EP 1719v2112https://develop.openfoam.com/Development/openfoam/-/merge_requests/518ENH: adjoint code review2022-06-15T09:36:08ZVaggelis PapoutsisENH: adjoint code review### Summary
An enhancement and review of the adjoint optimisation library, featuring
- the adjoint to the k-ω SST turbulence model
- easier and more accurate restarted runs
- reduced turnaround times
- reduced peak memory consumpti...### Summary
An enhancement and review of the adjoint optimisation library, featuring
- the adjoint to the k-ω SST turbulence model
- easier and more accurate restarted runs
- reduced turnaround times
- reduced peak memory consumption
### Resolved bugs
Partially resolves #2502, allowing the update of the nearWallDist field throughout an optimisation loop.
### Details of the code enhancement
Added the adjoint to the k-ω SST turbulence model for incompressible flows. This allows for avoiding the "frozen turbulence" assumption when using this turbulence model within an optimisation loop or when computing sensitivity maps. Making the "frozen turbulence" assumption, i.e. assuming that the turbulent viscosity field does not change when the shape changes throughout the optimisation, can lead to erroneously computed sensitivity derivatives. As an example, the drag sensitivity maps computed on the surface of the Ahmed body using the "frozen turbulence" assumption and the fully differentiated k-ω SST model are depicted below
![Ahmed_kOmega_back](/uploads/a6edbbd484421ef4cd8dfc6a147bbfb2/Ahmed_kOmega_back.png)
featuring areas where the sign of the sensitivity map changes when turbulence is not differentiated.
Taking this a step further and executing optimisations using "frozen turbulence" (FT) and "differentiated turbulence" (DT) highlights the need for differentiating the k-ω SST model in this case
![ahmed_kOmega_opt](/uploads/d742bb48fc2d9e34cf888ceb5f01afac/ahmed_kOmega_opt.png)
The DT approach reduces drag by more the 6% within 20 optimisation cycles whereas the optimisation based on the FT assumption diverges after the fourth cycle.
The work is based on [1] with changes in the discretisation of a number of differential operators and the formulation of the adjoint to the wall functions employed by the primal model.
**Source code**
$FOAM_SRC/optimisation/adjointOptimisation/adjoint/turbulenceModels/incompressibleAdjoint/adjointRAS/adjointkOmegaSST
**Examples**
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/naca0012/kOmegaSST/lift
$FOAM_TUTORIALS/incompressible/adjointOptimisationFoam/shapeOptimisation/sbend/turbulent/kOmegaSST/opt
**References**
[1] Kavvadias, I., Papoutsis-Kiachagias, E., Dimitrakopoulos, G., & Giannakoglou, K. (2014). The continuous adjoint approach to the k–$omega$ SST turbulence model with applications in shape optimization. Engineering Optimization, 47(11), 1523-1542. https://doi.org/10.1080/0305215X.2014.979816
**Attribution**
The initial implementation, as described in [1], was performed by Dr. Ioannis Kavvadias.
### Details of the code review
Three main aspects are addressed
- Continuation
Restarting a (partially) already ran optimisation is now easier and more accurate.
1. Adjoint solvers write/read their sensitivity derivatives under the 'uniform'
folder, to avoid potential loss of accuracy due to I/O.
2. Volumetric B-Splines control points of each optimisation cycle are written
under 'uniform' and support also binary I/O. As a consequence, the
controlPointsDefinition in constant/dynamicMeshDict does not need to be
changed to 'fromFile' anymore in order to perform the continuation, removing
a potential source of miss-setups.
3. The adjoint grid displacement field (ma) is now appended by the name of the
adjoint solver, if more than one exist. This facilitates continuation since,
before the change, only the ma field of the last adjoint solver was written
to file. No changes to fvSchemes/fvSolution are necessary though.
- Reduced turnaround times
A number of changes to reduce the solution turnaround time of the adjoint
equations (see bac1d8bae41c for details). In brief, these include caching of
some expensive but constant quantities and removing some coding shortcomings.
All cases should see some benefit (e.g. around 9.5% reduction in the turnaround
time of the adjoint solver for the motorbike tutorial) but the latter can be
even more pronounced in cases with many outlet boundaries.
- Reduced peak memory consumption
The peak memory consumption of the adjoint code is observed during the
computation of sensitivity derivatives, when using either the FI or the E-SI
approach, due to the need of manipulating a number of volTensorFields necessary
to compute the multiplier of the spatial gradient of the grid sensitivities.
This part of the code has been re-written to reduce this peak memory consumption.
### Risks
No changes to the user input, apart from the second item in the 'Continuation'
listing above, which should make the setup of continuation runs easier/more straightforward.
Additionally, sensitivities are now computed at the end of each adjoint solver,
instead of being computed when all adjoint solvers are finished, but this
should not affect the code behaviour and/or setup in any way.
Finally, even though 5937c37a resolves the main issue in #2502, it practically disables caching of gradients after the
first mesh update within an optimisation loop (see #2502 for a discussion).v2206Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/516New "exprField" function object2021-12-10T14:46:34ZMark OLESENNew "exprField" function object- provides a simple means of defining/modifying fields.
For example,
```
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- output field
expression "p + 0.5*(rho*magSqr(U))";
dime...- provides a simple means of defining/modifying fields.
For example,
```
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- output field
expression "p + 0.5*(rho*magSqr(U))";
dimensions [ Pa ];
}
// modify the above
<name1>
{
type exprField;
libs (fieldFunctionObjects);
field pTotal; //<- input/output field (for modify)
action modify;
// Static pressure only in these regions
fieldMask
#{
(mag(pos()) < 0.05) && (pos().y() > 0)
|| cellZone(inlet)
#};
expression "p";
};
```
![exprFieldFunctionObject](/uploads/bc7b302f3332186336d430ed8f29c60a/exprFieldFunctionObject.png)v2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/515ENH: patchProbes: output patch. Fixes #2291.2021-12-09T09:23:01ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comENH: patchProbes: output patch. Fixes #2291.### Summary
Add output to patchProbes header.
### Resolved bugs (If applicable)
#2291
### Risks
Output patch name only if global or originating from local processor### Summary
Add output to patchProbes header.
### Resolved bugs (If applicable)
#2291
### Risks
Output patch name only if global or originating from local processorAndrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/512INT: age/comfort: New field function objects2021-12-13T17:07:01ZKutalmış BerçinINT: age/comfort: New field function objects(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation...(Explanatory content by @THO - I just added/removed few things)
### Summary
#### Function object: age
This functionObject calculates the so called `age of air` inside any domain. This is useful in HVAC analysis to check the ventilation of a room, office, theater, cinema, academic rooms etc.
The function object is similar to use the `scalarTransport` function object + adding a source term via `fvOptions`. However, the main advantage of the `age` functionObject is that the user does not have to provide the `volScalarField`. It is generated automatically based on the patches a user uses:
- All patches of type patch (mainly used for inlet/outlets in HVAC) does get an `inletOutlet` boundary type while the `inletValue` is set to 0 (fresh air)
- All other patches of any other type, e.g., walls, are set to `zeroGradient`
- The `volScalarField` is generated during the execute routine - could be improved by checking if it is in the registry already, if yes take it otherwise create it
- For each time-step the steady-state solution of the age is calculated, and therefore the user can control the convergence:
- by setting the `tolerance` for the initial residual
- `nCorrs` for how many corrector loops are executed
- If either the `nCorrs` or the `tolerance` is reached, the loop is left and the field is stored
#### Function object: comfort
This functionObject calculated values based on the `ISO EN 7730:2005` for human behavior inside rooms. This is mainly used in HVAC analysis. The functionObject calculated (until now) three quantities:
PPD - predicted percentag of dissatisfaction
PMV - predicted mean vote
DR - draught rate
The calculations of PPD, PMV, and DR are normally single values for a single room: so its just rough guess. With CFD we have the possibility to evaluate each numerical cell separately and hence, HVAC analysis can predict more accurate and more understandable results. HVAC analysis also used for swimming bath, sauna areas and much more.
These quantities are based on the following computed fields:
Temperature
Velocity
Turbulent kinetic energy (if available)
Optional input parameters:
Clothing factor (what people wear - data are given in ISO EN 7730)
Methabolic rate
externalWork (commonly 0)
radiation temperature, if not given calculated based on surface-temperatures
relative humidity
saturation pressure, if not given will be calculated in the function object otherwise
tolerance (for the loop in a sub-function to calculate the clothing temperature)
maxClothIter (number of iterations to calculate the clothing temperature)
meanVelocity; either use the local cell velocity field for each
### Resolved bugs
N/A
### Details of new models
#### Function object: age
* Based on laboratory experiments:
```
Bartak, M., Cermak, M., Clarke, J.A., Denev, J.,
Drkal, F., Lain, M., Macdonald, I.A., Majer, M., Stankov, P., 2001.
Experimental and numerical study of local mean age of air.
In: Proceedings of the 7th International Building Performance
Simulation Association (IBPSA) Conference, Rio de Janeiro, Brazil.
Bartak, M., Beausoleil-Morrison, I., Clarke, J.A., Denev, J., Drkal, F.,
Lain, M., Macdonald, I.A., Melikov, A., Popiolek, Z., Stankov, P., 2002.
Integrating CFD and building simulation. Building and Environment 37, 865–871.
```
* A laboratory experiment of a test room with mixing ventilation, where the measurements were taken by a tracer-gas concentration-decay method.
* "At first a uniform tracer-gas distribution in the test room was reached, then the tracer-gas marking was cut off and the decay of the tracer-gas concentration due to the fresh (non-marked) ventilating air was measured."
![image](/uploads/cf5f1628cedd6258f2f37c20ff8b6ca2/image.png)
![image](/uploads/0e09e4056eca0fbf58582e17ebc4725b/image.png)
#### Function object: comfort
Unluckily, there is no validation case available for this function object. The only possible "check" is to use a one-cell domain, set parameters (as given in the EN ISO 7730:2005) and check if the same results are outputted.
### Risks
- No changes in user input
- No changes in existing outputv2112Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/511Update of interIsoFoam and isoAdvection extending to work with porous media2021-12-13T17:11:35ZJohan RoenbyUpdate of interIsoFoam and isoAdvection extending to work with porous mediaExtension of isoAdvection and interIsoFoam to deal with a porous medium
occupying part of the cell volumes and described by a porosity volScalarField
taking values larger than 0 (cell full of solid) and less than or equal to one
(cell f...Extension of isoAdvection and interIsoFoam to deal with a porous medium
occupying part of the cell volumes and described by a porosity volScalarField
taking values larger than 0 (cell full of solid) and less than or equal to one
(cell full of fluid).
The current implementation deals with both the advection part of the problem
and the modification of the UEqn (p_rghEqn needs no changes).
The aim of the implementation is to make it invisible to the user who does not
work with porosity both in terms of efficiency, memory usage and code complexity.
It would be preferable if the required interIsoFaom changes could be done without
touching the solver files, e.g. implementing the UEqn modifications as an fvOption.
This seems to be impossible because we need to modify the existing terms in the
UEqn and the fvMatrix is build from right to left meaning the fvOption cannot
touch e.g. the fvm::div(rhoPhi,U)-term. The chosen solution is therefore to add an
#include "UEqnAddPorosity.H" line to the UEqn.H file AFTER the UEqn is constructed.
The activation of porosity treatment is controlled by a bool parameter called
porosityEnabled in a constant/porosityProperties dictionary. This is disabled by default.
If it is enabled the user must provide a porosity volScalarField in the 0 time dir.
The isoAdvection class has two new data members: porosityPtr_ to the porosity field,
is nullptr by default, and a bool called porosityEnabled_ (default false) read
from the constant/porosityProperties by the isoAdvection constructor.
It has been necessary to introduce "if (porosityEnabled_)" lines various places in
the code but most places this is not inside loops over cells or faces so it is
cheap. An exception is in the isoAdvection bounding functions but these are only
called for very few cells so this should not be very expensive.
At this point I am not sure that the interplay with the source terms Su and Sp.
These should probably also be divided by porosity when alpha is updated.
The interIsoFoam solver now reads the porosityEnabled bool in constant/
porosityProperties,reads the porosity field if needed and the porosity parameters
for the Darcy-Forchheimer force and added mass force from the constant/
porosityProperties dict.
I have introduced a porousAlphaCourantNo.H and porousCourantNo.H file as
replacements for alphaCourantNo.H and CourantNo.H to correct the adaptive time
stepping so it accounts for the increased flow velocity in porous cells if
porosity is enabled.
Also the "Phase-1 volume fraction" write out has been modified to take porosity
properly into account.
There are two test cases included:
1. discInConstantPorousFlow which is the same as discInConstantFlow but with a
porous zone in the middle of the domain where the disc elongates and moves faster.
2. A porousDamBreak testing porosity implementation and comparing with exp. data.
This code contribution is joined work between:
- Konstantinos Missios
- Niels Gjøl Jacobsen
- Henning Scheufler
- Johan Roenby
Johan Roenby, December 2021v2112Andrew HeatherAndrew Heatherhttps://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/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/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 Heather