openfoam merge requestshttps://develop.openfoam.com/Development/openfoam/-/merge_requests2021-06-22T09:18:22Zhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/454ENH: turbulentDFSEMInlet: various improvements2021-06-22T09:18:22ZKutalmış BerçinENH: turbulentDFSEMInlet: various improvements### Summary
- ENH: Input entries of `R`, `L` and `U` are now `PatchFunction1` type.
- ENH: Adds two scalar normalisation factors for input `R`, `L` and `U`: `Uref` and `Lref` (default=1).
- ENH: Adds a scalar factor to enable users to t...### Summary
- ENH: Input entries of `R`, `L` and `U` are now `PatchFunction1` type.
- ENH: Adds two scalar normalisation factors for input `R`, `L` and `U`: `Uref` and `Lref` (default=1).
- ENH: Adds a scalar factor to enable users to tune the C1 normalisation coefficient: `scale` (default=1).
- BUG: MappedFile: separates scopes of entries.
- TUT: Replaces `chan395DFSEM` and `PCF` tutorials with `planeChannel` and `oneCellThickPlaneChannel` tutorials.
- Corrects the integral-length scale input files.
- Updates the [Extended Code Guide's channel flow](https://www.openfoam.com/documentation/guides/latest/doc/verification-validation-turbulent-plane-channel-flow.html) case, and allows users to reproduce the results.
### Resolved bugs (If applicable)
#2098
#2097
#2090
#1004
#1744
#2089
### Details of new models (If applicable)
A set of results obtained from the `planeChannel` tutorial (and its plot script available to users) with a different set of settings can be seen below:
##### Ruv vs y
![Ruv_vs_y](/uploads/0a9a5a8b41f5c19a8ccacc3d1614d554/Ruv_vs_y.png)
##### u vs y
![u_vs_y](/uploads/e43ae1708a96ba6c77955d33e4ebf5ca/u_vs_y.png)
##### Ruu vs y
![Ruu_vs_y](/uploads/d30bcba9424ab2cf2fd63f9ebcb41285/Ruu_vs_y.png)
##### x vs Cf
![x_vs_cf](/uploads/c7f25cfb42129756c84d9a76ce010170/x_vs_cf.png)
##### Rvv vs y
![Rvv_vs_y](/uploads/aa956075682e9331172a0ddbd92ab727/Rvv_vs_y.png)
##### Rww vs y
![Rww_vs_y](/uploads/00cdcd67ba65659f8469c59415a46d23/Rww_vs_y.png)
### Risks
##### User input
Users (my apologies) will have to change the input syntax for `R`, `L` and `U` entries. For example, for reading the input files in `constant/boundaryData/inlet/0/`, users were using the following minimal syntax:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
mapMethod nearestCell;
value $internalField;
}
```
For the same effect, one of the syntax examples could be as follows:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
U mappedFile;
R mappedFile;
L mappedFile;
mapMethod nearest;
value $internalField;
}
```
or as follows:
```
inlet
{
type turbulentDFSEMInlet;
delta 1;
U
{
type mappedFile;
mapMethod nearest;
}
R
{
type mappedFile;
mapMethod nearest;
}
L
{
type mappedFile;
mapMethod nearest;
}
value $internalField;
}
```
Users can, however, use any of the `PatchFunction1` input syntax exemplified in this [link](https://www.openfoam.com/news/main-news/openfoam-v1812/core#core-patch-function1) and this [link](https://www.openfoam.com/news/main-news/openfoam-v20-06/pre-processing#pre-processing-expression-patchfunction1).
##### Regressions
- ~~The default value of `nCellPerEddy` entry was changed from 5 to 1, which is the default value corresponding to the original journal paper.~~
- The default value of `nCellPerEddy` entry was kept the same as 5.
##### Remaining issues
- Arguably, the DFSEM method has various theoretical issues that need to be addressed (see #2090). We have been trying to reach the originators of the method during the last couple of years; and we will continue our efforts, if possible, to cooperate with them to resolve some of these issues.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/451TUT: finiteArea: clean up tutorials2021-06-09T13:41:55ZKutalmış BerçinTUT: finiteArea: clean up tutorials[old-testLoopReport.gz](/uploads/9cba8c30d2af84df40afefabf33a3565/old-testLoopReport.gz)
[new-testLoopReport.gz](/uploads/e9a555b45ae7beb188d78198e359ba56/new-testLoopReport.gz)
[old-logs.gz](/uploads/b51c81ef8a656bf373b5d76c3a31d395/o...[old-testLoopReport.gz](/uploads/9cba8c30d2af84df40afefabf33a3565/old-testLoopReport.gz)
[new-testLoopReport.gz](/uploads/e9a555b45ae7beb188d78198e359ba56/new-testLoopReport.gz)
[old-logs.gz](/uploads/b51c81ef8a656bf373b5d76c3a31d395/old-logs.gz)
[new-logs.gz](/uploads/217a781a7a9a5a1845de65dc7ae4acfb/new-logs.gz)v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/450ENH: update geoVoF module (#2076)2021-06-24T16:48:11ZHenning ScheuflerENH: update geoVoF module (#2076)@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the test...@johan_roenby
Changes:
* renamed interface fields recon::centre -> interfaceCentre.{phaseName}
* interface fields are not written by default
* compatible with AMR and load balancing
Status:
* all tests and tutorial cases pass
the testsuite is not included in the commits but is available in issue #2076.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/449refactor and extend handling of faSchemes/fvSchemes2021-05-14T18:36:39ZMark OLESENrefactor and extend handling of faSchemes/fvSchemesv2106Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/merge_requests/447STYLE: PDRFOAM End of Program was inconsistent with other applications2021-06-18T13:18:00ZHenning ScheuflerSTYLE: PDRFOAM End of Program was inconsistent with other applicationsfixes issue #2091fixes issue #2091v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/446collected changes for Lists, faces and PrimitivePatch2021-05-13T10:53:04ZMark OLESENcollected changes for Lists, faces and PrimitivePatchv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/445add multi-region handling for checkMesh etc, centralized the region handling...2024-01-05T16:57:08ZMark OLESENadd multi-region handling for checkMesh etc, centralized the region handling #2072Introduces a few new include files that simplify and improve the code structure for multi-region utilities
- addAllRegionOptions.H
- getAllRegionOptions.H
- createNamedMeshes.HIntroduces a few new include files that simplify and improve the code structure for multi-region utilities
- addAllRegionOptions.H
- getAllRegionOptions.H
- createNamedMeshes.Hv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/443ENH: CloudFunctionObject: new particle function objects2021-06-08T20:35:31ZKutalmış BerçinENH: CloudFunctionObject: new particle function objects### Summary
* acec5badc7 - ENH: lagrangian: add new CloudFunctionObjects
- New cloud function objects:
- ReynoldsNumber (for kinematic parcels, i.e. KinematicReynoldsNumber)
- ReynoldsNumber (for thermo/reacting parcels, i...### Summary
* acec5badc7 - ENH: lagrangian: add new CloudFunctionObjects
- New cloud function objects:
- ReynoldsNumber (for kinematic parcels, i.e. KinematicReynoldsNumber)
- ReynoldsNumber (for thermo/reacting parcels, i.e. ThermoReynoldsNumber)
- NusseltNumber
- HeatTransferCoeff
* 83e3043dec - ENH: lagrangian: split macros for CloudFunctionObjects
- three macros:
- makeParcelCloudFunctionObjects for kinematic parcels
- makeThermoParcelCloudFunctionObjects for thermo parcels
- makeReactingParcelCloudFunctionObjects for reacting parcels
* 4c13f687b7 - DOC: lagrangian: review heat transfer models
* 2107c10f3b - ENH: RanzMarshall: generalises the Nusselt-number correlation
* 3d14d3f7ec - ENH: rhoThermos: enable transport:tabulated + equationOfState:icoPolynomial
### Details of new models (If applicable)
- See the header file documentations for the details.
- Users can enable the cloud FOs as follows:
```
cloudFunctions
{
ReynoldsNumber1
{
type ReynoldsNumber;
// picks kinematic or thermo Reynolds number FO
// based on the operand cloud type.
// e.g. for sprayFoam, the ThermoReynoldsNumber
// is activated in the background.
}
NusseltNumber1
{
type NusseltNumber;
}
HeatTransferCoeff1
{
type HeatTransferCoeff;
}
}
```
- Various results in comparison to experimental results reported in [Buist et al., (2017)](https://www.doi.org/10.1016/j.ces.2016.04.022):
![Re_vs_Nu](/uploads/8ded0601dcdd0e3344349715ed0523e7/Re_vs_Nu.png)
- Users can also input custom values for the correlation coefficients in the Ranz-Marshall correlation, e.g.:
```
subModels
{
RanzMarshallCoeffs
{
a 2.0;
b 0.6;
m 0.5;
n 0.6666;
}
}
```
### Risks
- No change to the previous output state or to the user input
- Alltest: pass [logs.gz](/uploads/d4852ee2206ee4928ce7734be9b43aea/logs.gz) [testLoopReport.gz](/uploads/860a89f5cc0f5abbc17da65e32301518/testLoopReport.gz)
- sprayFoam/aachenBomb: pass (parallel:random)
- Doxygen: pass
- clang/gcc compilations: passv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/442consistency improvements for regex and hashes, etc2021-04-19T16:34:10ZMark OLESENconsistency improvements for regex and hashes, etcAccumulated changes/fixes for improving consistency.
- fileName : improve handling of windows-style path separators
- wordRe / keyType : reduce code duplication in favour of using wordRe more consistently
- hashes : rejig hashing overlo...Accumulated changes/fixes for improving consistency.
- fileName : improve handling of windows-style path separators
- wordRe / keyType : reduce code duplication in favour of using wordRe more consistently
- hashes : rejig hashing overloads and class-local versions to improve future extensibilityv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/441ENH: SpalartAllmaras: add estimation functions for k, epsilon and omega2021-05-27T08:59:07ZKutalmış BerçinENH: SpalartAllmaras: add estimation functions for k, epsilon and omega### Summary
- Adds estimation functions for `k`, `epsilon`, `omega` fields into the `SpalartAllmaras` turbulence closure model, so that various utilities can be enabled with this model if necessary, e.g. `turbulenceFields` function obje...### Summary
- Adds estimation functions for `k`, `epsilon`, `omega` fields into the `SpalartAllmaras` turbulence closure model, so that various utilities can be enabled with this model if necessary, e.g. `turbulenceFields` function object.
- Reduces peak-memory usage in the `SpalartAllmaras` model.
### Resolved bugs
N/A
### Details of new models
- The first test case was based on a direct-numerical simulation
by (Moser et al., 1999). The test case is a smooth-wall turbulent
plane channel flow wherein an internal flow statistically develops downstream
(until is fully developed) through parallel smooth walls that are two
characteristic-length apart. The friction Reynolds number of the flow is
$`\mathrm{Re}_\tau = 180`$.
##### Turbulent kinetic energy
<img src="/uploads/b0cf7d41b347137dc29afe6a16776929/all_setups_yPlus_vs_kPlus1.png" width="50%" height="50%"/>
##### Turbulent kinetic energy dissipation rate
<img src="/uploads/c3349de9e0923e438206b9a2d4fa3a3d/all_setups_yPlus_vs_epsilonPlus.png" width="50%" height="50%"/>
##### Turbulent kinetic energy production rate
<img src="/uploads/7fe9b01e82dafe5a40e30190a76f0d51/all_setups_yPlus_vs_productionRatePlus.png" width="50%" height="50%"/>
##### Streamwise flow speed
<img src="/uploads/9f9fd069fcb7e6d9762b52e7f250d8c0/all_setups_yPlus_vs_uPlus.png" width="50%" height="50%"/>
##### Reynolds stress tensor components
<img src="/uploads/c4c631ee9e2a487c7475f34e3c6bb476/all_setups_yPlus_vs_Ruv.png" width="50%" height="50%"/>
<img src="/uploads/982bc15a688f2388778f22bc4e3445c0/all_setups_yPlus_vs_Rww.png" width="50%" height="50%"/>
<img src="/uploads/038dda65b4c2e4015013c58f7812529f/all_setups_yPlus_vs_Rvv.png" width="50%" height="50%"/>
<img src="/uploads/5e174efaba0470289ba83133942238b9/all_setups_yPlus_vs_Ruu.png" width="50%" height="50%"/>
### Risks
No known risks or user-input changes.
PS: Hi @vaggelisp, might affect or be relevant? just for your info in any case.v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/440ENH: DMD: refactor dynamic mode decomposition FO2021-04-26T15:00:55ZKutalmış BerçinENH: DMD: refactor dynamic mode decomposition FO#### Summary
##### Feature-1: Refactoring the dynamic mode decomposition (DMD) module
In `v2006`, OpenFOAM had learned a function object capability called “Streaming Total Dynamic Mode Decomposition” (i.e. `STDMD`) which was a variant ...#### Summary
##### Feature-1: Refactoring the dynamic mode decomposition (DMD) module
In `v2006`, OpenFOAM had learned a function object capability called “Streaming Total Dynamic Mode Decomposition” (i.e. `STDMD`) which was a variant of dynamic mode decomposition method (i.e. data-driven/equation-free dimensionality reduction method).
Although the `STDMD` was observed to provide the general DMD method capabilities alongside economised and feasible memory and CPU usage, in the last decade or so, many variants arose, "such as multiresolution DMD, compressed DMD, forward backward DMD, and higher order DMD among others, in order to deal with noisy data, big dataset, or spurious data for example."
This set of commits allows developers/users to implement their own DMD models by providing them a more user-friendly interface and class hierarchies within a new `DMD` module.
##### Feature-2: Enabling `postProcess` utility
`STDMD` could operate on run time by using `system/controlDict.functions`, i.e. the data processing that is performed during the running of an ongoing simulation.
However, `STDMD` could not operate as a postprocessing routine, i.e. the data processing activity that occurs after a simulation has run.
This set of commits provides the required capabilities to execute a `DMD` model on ascii/binary OpenFOAM fields that are already written by an OpenFOAM simulation after either a serial or parallel computation.
The new implementation allows a `DMD` model to be executed by using the `postProcess` utility after a simulation is completed, and required fields are written.
A minimal example by using the `postProcess` utility can be as follows (the utility reads the `DMD` settings from `system/controlDict.functions`):
<solver> -postProcess -fields '(U p)' -time '10:'
##### Feature-3: Enabling operations on patch fields
`STDMD`could operate on a given `{vol,surface}<Type>Field` where `<Type>` can be either of the OpenFOAM object types: `scalar`, `vector`, `symmetricTensor` or `tensor`.
However, `STDMD` could not operate on an input patch field, such as `wallShearStress`.
This set of commits provides the required capabilities to execute a `DMD` model on a given patch field for selected patch(es) in serial and parallel modes during an ongoing computation or during a postprocessing activity.
Selection of a certain group of patches instead of operating on all patches has been ensured, reportedly, "to constrain the input data to specific patches, not only for data reduction, but also to prevent from inserting constant entries into the `DMD` snapshots", a situation for which no concrete theoretical information is available (i.e. it is not well known "what happens to `DMD` if a majority of snapshot contents do not change over time.")
#### Resolved bugs (If applicable)
N/A
#### Details of new models (If applicable)
Please see the header-file documentations available in
- `DMD.H`
- `DMDModel.H`
- `STDMD.H`
#### Risks
A given set of settings for `v2006`-`STDMD` could not be run with this set of commits. Having said that the user input changes are self explanatory and can easily be performed.
Also, developers/users had been kindly warned in `v2006` by the following hard-coded warning stream:
```c
Info<< nl
<< " ### This STDMD release is the beta release ###" << nl
<< " Therefore small-to-medium changes in input/output interfaces "
<< "and internal structures should be expected in the next versions."
<< endl;
```v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/435ENH: refactor Function1 to enable fields2021-03-29T13:55:44ZKutalmış BerçinENH: refactor Function1 to enable fields- [x] do a clean rebuild of the whole tree
- [x] Alltest- [x] do a clean rebuild of the whole tree
- [x] Alltestv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/431ENH: solarLoad: new load model, timeDependent2021-03-31T10:13:54ZKutalmış BerçinENH: solarLoad: new load model, timeDependent### Summary
- `TimeFunction1` input for direct solar irradiation (w/m2)
- `TimeFunction1` input for diffuse solar irradiation (w/m2)
- `TimeFunction1` input for `spectralDistribution`
### Details of new models (If applicable)
The foll...### Summary
- `TimeFunction1` input for direct solar irradiation (w/m2)
- `TimeFunction1` input for diffuse solar irradiation (w/m2)
- `TimeFunction1` input for `spectralDistribution`
### Details of new models (If applicable)
The following entry set in the `simpleCarSolarPanel` tutorial produces the attached animation:
```
sunLoadModel timeDependent;
directSolarRad table
(
(0 500)
(5 500)
(10 0)
);
diffuseSolarRad 0;
spectralDistribution table
(
(0 (2.0 1.2))
(1 (1.1 1.3))
);
```
[animation-Qprimary-fps1.avi](/uploads/da0024e0ed222190543e189e7691247c/animation-Qprimary-fps1.avi) (animation is prepared by Alseny Diallo).
### Risks
No changes in user input or simulation output.
There seems to be a previous bug in `solarLoad` model, where `wallCoupled` entry was undefined in one of the constructors. We have fixed this bug; however, the fix is not backward compatible since we cannot define an undefined behaviour. For this reason, you may need to add `wallCoupled` keyword to the `radiationProperties` dictionary to keep all output the same from one version to the next, otherwise `qr` field content may end up being always zero for some cases.
[EP#1484](https://exchange.openfoam.com/node/1484)v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/430file "meta" information2021-03-16T08:49:23ZMark OLESENfile "meta" information- harmonization of list IO
- add meta information into Zones files, for easier inspection and downstream use of the files- harmonization of list IO
- add meta information into Zones files, for easier inspection and downstream use of the filesv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/428ENH: Improvement to overset that allows multiple motion solvers2021-03-17T09:08:39ZSergio FerrarisENH: Improvement to overset that allows multiple motion solversImprovement to overset that allows multiple motion solvers to operate with overset
1) Adding zoneMotion to rigidBodyMotion
2) Introducing PID to prescribedRotation restraint
3) Making drivenLinearMotion read total displacement
4) When dr...Improvement to overset that allows multiple motion solvers to operate with overset
1) Adding zoneMotion to rigidBodyMotion
2) Introducing PID to prescribedRotation restraint
3) Making drivenLinearMotion read total displacement
4) When drivenLinearMotion is used sixDof and rigid-body solvers
write total displacementv2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/422PtrListOps and adjustments for sync2021-02-09T19:04:05ZMark OLESENPtrListOps and adjustments for sync- spillover from 2020 that was too close to release time.
- conciser form when handling cyclic and processor patches (avoids double dynamic_cast).- spillover from 2020 that was too close to release time.
- conciser form when handling cyclic and processor patches (avoids double dynamic_cast).v2106Andrew HeatherAndrew Heatherhttps://develop.openfoam.com/Development/openfoam/-/merge_requests/420BUG: fixing various bugs for v21062021-06-09T14:28:53ZKutalmış BerçinBUG: fixing various bugs for v2106v2106Andrew 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 1719v2112