Development issueshttps://develop.openfoam.com/groups/Development/-/issues2018-05-29T05:39:49Zhttps://develop.openfoam.com/Development/openfoam/-/issues/357mapFields, setFields, dsmcInitialise not working on install2018-05-29T05:39:49ZAdminmapFields, setFields, dsmcInitialise not working on installI have recently installed OpenFOAM v1606+ on my ubuntu 16.10 machine. I followed every step on - http://openfoam.com/download/install-source.php and then went on to the build guide - http://openfoam.com/code/build-guide.php
The solve...I have recently installed OpenFOAM v1606+ on my ubuntu 16.10 machine. I followed every step on - http://openfoam.com/download/install-source.php and then went on to the build guide - http://openfoam.com/code/build-guide.php
The solvers has seemed to have installed fine but some applications (as when I do i.e. icoFoam -help or dsmcFoam -help, it doesn't say command not found) hasn't installed it seems. I have been doing some basic OpenFOAM tutorials and have come across that mapFields (Lid driven Cavity tutorial) and setFields (Dambreak tutoria) and dsmcInitialise (dsmcFoam tutorial) isn't working, which means I can't move forward with the tutorials and in turn my research.
[Edit: I removed the listing of Allwmake, since it doesn't help]
I don't know if this is the source of the error, I really want my OpenFOAM to work, I have wasted one whole day reinstalling it as I thought it would somehow fix itself once I remove and re-install it again but it hasn't.https://develop.openfoam.com/Development/openfoam/-/issues/69BUG: applyBoundaryLayer - inconsistent at processor boundaries and refinement...2016-03-15T09:20:11ZPrashant SonakarBUG: applyBoundaryLayer - inconsistent at processor boundaries and refinement regionsThe transition cells for refinement and processor boundaries seem to have inconsistnet results when using applyBoundaryLayer utility.
Attached example and obtained result.
@andy @Mattijs
[pitzDaily_appyBoundaryLayer_issue.tgz]...The transition cells for refinement and processor boundaries seem to have inconsistnet results when using applyBoundaryLayer utility.
Attached example and obtained result.
@andy @Mattijs
[pitzDaily_appyBoundaryLayer_issue.tgz](/uploads/57889de79ee3a0a1b29b8024b44e4b64/pitzDaily_appyBoundaryLayer_issue.tgz)
![k_after_applyBundaryLayer_pitzDaily](/uploads/7184a83105f9c8352cabd6b85af44e89/k_after_applyBundaryLayer_pitzDaily.png)
Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1050Packaging for multiple distributions2020-03-13T13:41:50ZAdminPackaging for multiple distributionsWith regards to a discussion with Mark Olesen about having OpenFOAM packages being built on the Open build service (OBS) for the major distributions.
\## Reattaching the author to the issue ticket: @gsg001 ##With regards to a discussion with Mark Olesen about having OpenFOAM packages being built on the Open build service (OBS) for the major distributions.
\## Reattaching the author to the issue ticket: @gsg001 ##Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/296Native ofs format appears to be broken.2017-01-02T12:22:58ZMark OLESENNative ofs format appears to be broken.This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass arou...This format is little-used, but relying on raw stream operators for the native format breaks down when different face types (face vs. triFace vs. labelledFace) are being used. It is still reasonable to have stream operators for pass around data (eg, between processors), but they shouldn't be used for files. Otherwise we can easily create a binary file using triFace or labelledFace and not be able to read it back with normal face.
Additionally, the static OFSsurfaceFormat::read functions are too fragile (broken).
Suggest removing entirely. @andyVersion v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1304template specialization for processorFvPatchScalarField2023-12-07T19:00:15ZMark OLESENtemplate specialization for processorFvPatchScalarField@andy @Mattijs
While doing the mingw port I keep hitting a very strange compilation issue. It complains about duplicate thunks for
`processorFvPatchField<scalar>::initInterfaceMatrixUpdate` etc. Oddly enough, it doesn't have any proble...@andy @Mattijs
While doing the mingw port I keep hitting a very strange compilation issue. It complains about duplicate thunks for
`processorFvPatchField<scalar>::initInterfaceMatrixUpdate` etc. Oddly enough, it doesn't have any problem with `processorFaPatchField<scalar>::initInterfaceMatrixUpdate` which is structured exactly the same way.
I've looked high and low, but can't find anything indicating duplicate inclusion of the file. Also tried with including the declaration of the specialization into `processorFvPatchField.H` itself.
To make a virtue out of a necessity, I simply discarded the specialization and made an 'in-line' specialization within
`processorFvPatchField.C` itself. For example,
```
// Consume straight from scalarReceiveBuf_
if (!std::is_fundamental<Type>::value)
{
// Transform according to the transformation tensor
transformCoupleField(scalarReceiveBuf_, cmpt);
}
```
This will skip the transformCoupleField for label, scalar, solveScalar etc and thus does the same as the template specialization. For C++11, the compiler will presumably be intelligent enough to remove this as unused code (depending on the type). For C++17 the if-constexpr means that it will definitely be removed, as if it were a templated bit of code.
From my perspective, I think that this would be a reasonably good change to make since it does remove some code duplication (and helps with my compilation).
- Anything that I might be missing?
- Any other places with template specialization could also be addressed like this?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1100Possible Deprecation of turbulentInlet Boundary Condition2019-12-18T16:20:29ZKutalmış BerçinPossible Deprecation of turbulentInlet Boundary ConditionHi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/docu...Hi,
**turbulentInlet** boundary condition generates fluctuating velocity fields by superimposing (pseudo-)random number sets (scaled by a given turbulence intensity) onto a reference (mean) velocity field.
https://www.openfoam.com/documentation/cpp-guide/html/classFoam_1_1turbulentInletFvPatchField.html
Although this approach was proposed in the literature as the first turbulence inflow method, numerous studies quantified its ineffectiveness (refs can be provided if need be). Unfortunately, turbulence is fully deterministic and involving various spatial/temporal coherent structures, yet is random in a sense that its stochastic development cannot be predicted, again due to its acute sensitivity to initial/boundary conditions.
For example, in detail, for turbulentInlet the energy of generated time-series is equally distributed over the whole wavenumber range, that means the spectrum is approximately a horizontal line. Therefore, due to a lack of energy in the low wave number range, the pseudo turbulence is immediately damped to zero when enters into a CFD domain, and the result is virtually identical with a laminar inflow.
For these reasons, I kindly suggest a discussion as to this module's deprecation since customers/developers/users could be misled by its name and offerings.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/926Use vtm output for OpenFOAM to VTK translation2018-12-21T18:07:47ZMark OLESENUse vtm output for OpenFOAM to VTK translationThe current foamToVTK and vtkWrite (function object) write legacy files on a per-processor basis. This should be adjusted to use the vtm (multi-block) format that incorporates a vtu file for the internal mesh and vtp files for the bounda...The current foamToVTK and vtkWrite (function object) write legacy files on a per-processor basis. This should be adjusted to use the vtm (multi-block) format that incorporates a vtu file for the internal mesh and vtp files for the boundary patches.
The realization might entail collection on the master, or aggregates.
The output shall contain all relevant fields within each timestep file. v1812Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/334BUG : foamToEnsight -faceZones still crashes sometimes in develop2018-05-29T05:39:49ZAdminBUG : foamToEnsight -faceZones still crashes sometimes in developPossibly related to #317, foamToEnsight -faceZones still crashes sometimes. I tested with the latest develop commit.
The example model is attached and is a simple pipe with a few faceZones and a cellZone created during meshing. When...Possibly related to #317, foamToEnsight -faceZones still crashes sometimes. I tested with the latest develop commit.
The example model is attached and is a simple pipe with a few faceZones and a cellZone created during meshing. When foamToEnsight -faceZones is run at the end, it crashes and goes into a large loop of errors.
![Capture](/uploads/bdfad5480880eef1f3f574a6e027b74e/Capture.PNG)
[tube_test_inter.tar.gz](/uploads/8fb9d819bf61cf3d317df22fa09ccd0c/tube_test_inter.tar.gz)Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/132foamToEnsight crash when patch name > 80 char2016-06-30T22:09:38ZAdminfoamToEnsight crash when patch name > 80 charin OpenFOAM2.2.1 when using foamToEnsight binary output, if the patch name is equal or greater then 80 characters, it crashes. The crash can be avoided by doing the following modification:
```
+++ b/applications/utilities/postProcessi...in OpenFOAM2.2.1 when using foamToEnsight binary output, if the patch name is equal or greater then 80 characters, it crashes. The crash can be avoided by doing the following modification:
```
+++ b/applications/utilities/postProcessing/dataConversion/foamToEnsight/ensightBinaryStream.H
@@ -98,7 +98,7 @@ public:
virtual void write(const char* val)
{
char buffer[80] = {0};
- strcpy(buffer, val);
+ strncpy(buffer, val, 80);
str_().write(buffer, 80*sizeof(char));
}
```
The same crash happens with OpenFOAM-v3.0+. Would it be possible to use the above modification to fix ensightBinaryStream.H?
Thank you
AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/1389Clang problem reading wild cards2020-02-03T06:15:15ZSergio FerrarisClang problem reading wild cardsClang has problems reading wild cards such as "(U|k|epsilon|s).*".
It doesn't expand it correctly thus, the error: Entry 'epsilonFinal' not found in dictionary.....Clang has problems reading wild cards such as "(U|k|epsilon|s).*".
It doesn't expand it correctly thus, the error: Entry 'epsilonFinal' not found in dictionary.....https://develop.openfoam.com/Development/openfoam/-/issues/297unallocated list in triSurface vtk reader (non-critical)2016-12-15T21:07:15ZMark OLESENunallocated list in triSurface vtk reader (non-critical)Condition is there to catch cases where the vtkSurfaceFormat returns 0 zones (which should never be the case), but assigns a fall-back value without resizing the list first.Condition is there to catch cases where the vtkSurfaceFormat returns 0 zones (which should never be the case), but assigns a fall-back value without resizing the list first.Version v1612Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/34BUG: Unit test findings - 14 Dec 20152015-12-17T12:52:19ZPrashant SonakarBUG: Unit test findings - 14 Dec 2015@Mattijs
All tests under: /home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest.14Dec
- keyword transmissivityModel is undefined in constant/baffle3DRegion/radiationProperties
Case: heatTransfer/buoyantSimple...@Mattijs
All tests under: /home/alex2/prashant/OpenFOAM/OpenFOAM-dev-OpenCFD.develop/tutorialsTest.14Dec
- keyword transmissivityModel is undefined in constant/baffle3DRegion/radiationProperties
Case: heatTransfer/buoyantSimpleFoam/circuitBoardCoolingFunctionality migration from internal development lineSergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1257Error in compiling solver in OpenFOAM-v1806 on windows2020-03-13T13:36:43ZAdminError in compiling solver in OpenFOAM-v1806 on windowsDear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to r...Dear all,
I have tried to compile a solver on a newly installed OpenFOAM-v1806 on windows without success. I have installed make, build-essentials, all to no avail. This happened on two different computers. As a test case, I decided to recompile the original reactingTwoPhaseEulerFoam without modifying it but alwyas gets the error below:
g++ -std=c++11 -m64 -DOPENFOAM=1806 -Dlinux64 -DWM_ARCH_OPTION=64 -DWM_DP -DWM_LABEL_SIZE=32 -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-attributes -Wno-unknown-pragmas -O3 -DNoRepository -ftemplate-depth-100 -ItwoPhaseSystem/lnInclude -I../phaseSystems/lnInclude -I../interfacialModels/lnInclude -I../interfacialCompositionModels/lnInclude -ItwoPhaseCompressibleTurbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/thermophysicalModels/basic/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/transportModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/turbulenceModels/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/compressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/TurbulenceModels/phaseCompressible/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/meshTools/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/sampling/lnInclude -IlnInclude -I. -I/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude -I/opt/OpenFOAM/OpenFOAM-v1806/src/OSspecific/POSIX/lnInclude -fPIC -c reactingTwoPhaseEulerFoam.C -o /opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o
In file included from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/scalar.H:39:0,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/IOstream.H:49,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Ostream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/OSstream.H:39,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/messageStream.H:244,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/error.H:51,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UListI.H:26,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UList.H:532,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/List.H:43,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/labelList.H:60,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/UPstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/Pstream.H:42,
from /opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/parRun.H:38,
from /opt/OpenFOAM/OpenFOAM-v1806/src/finiteVolume/lnInclude/fvCFD.H:4,
from reactingTwoPhaseEulerFoam.C:39:
**/opt/OpenFOAM/OpenFOAM-v1806/src/OpenFOAM/lnInclude/floatScalar.H:54:1: internal compiler error: Illegal instruction
constexpr floatScalar floatScalarGREAT = 1.0e+6;**
^~~~~~~~~
0xac5ddf crash_signal
/home/pgh/OpenFOAM/ThirdParty-1706/gcc-6.3.0/gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
/opt/OpenFOAM/OpenFOAM-v1806/wmake/rules/General/transform:34: recipe for target '/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o' failed
make: *** [/opt/OpenFOAM/OpenFOAM-v1806/build/linux64Gcc63DPInt32Opt/applications/solvers/multiphase/reactingEulerFoam/reactingTwoPhaseEulerFoam/reactingTwoPhaseEulerFoam.o] Error 1
\#\# Reattaching the author to the issue ticket: @dela \#\#
https://develop.openfoam.com/Development/openfoam/-/issues/571BUG: Unable to create a List from a SLList2019-12-09T22:11:26ZAdminBUG: Unable to create a List from a SLListOn beahlf of @hjasak
The following code fails
```
int main(int argc, char *argv[])
{
SLList<label> a;
List<label> b(a);
return 0;
}
```
With the error message
```
src/OpenFOAM/lnInclude/ListI.H:94:35: error: invalid type a...On beahlf of @hjasak
The following code fails
```
int main(int argc, char *argv[])
{
SLList<label> a;
List<label> b(a);
return 0;
}
```
With the error message
```
src/OpenFOAM/lnInclude/ListI.H:94:35: error: invalid type argument of unary '*' (have 'int')
this->operator[](i) = *iter;
```v1712AdminAdminhttps://develop.openfoam.com/Development/openfoam/-/issues/638foamListTimes disappeared; still used in tutorials2017-12-18T05:11:06ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comfoamListTimes disappeared; still used in tutorialsMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/796decompositionMethod::decompose functions are non-const2023-12-07T19:03:32ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdecompositionMethod::decompose functions are non-constI cannot immediately see why the decompose member functions are non-const.I cannot immediately see why the decompose member functions are non-const.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/946turbulentHeatFluxTemperature doesn't work with buoyantBoussinesqPimpleFoam2018-10-09T08:54:26ZAdminturbulentHeatFluxTemperature doesn't work with buoyantBoussinesqPimpleFoamHi,
I am using OF 1612 on Centos 7, it was installed by following the tutorial on OFWiki.
I am currently modifying the hotRoom tutorial case under solver buoyantBoussinesqPimpleFoam to specify a constant heat flux at the floor. The mod...Hi,
I am using OF 1612 on Centos 7, it was installed by following the tutorial on OFWiki.
I am currently modifying the hotRoom tutorial case under solver buoyantBoussinesqPimpleFoam to specify a constant heat flux at the floor. The modified BC for T is as below:
```
boundaryField
{
floor
/*{
type fixedValue;
value uniform 300; // Original
}*/
{
type compressible::turbulentHeatFluxTemperature;
heatSource flux;
q uniform 10e5;
value uniform 293.15;
kappaMethod fluidThermo;
kappa none;
Qr none;
}
ceiling
{
type fixedValue;
value uniform 300;
}
fixedWalls
{
type zeroGradient;
}
}
```
I think I followed the example set in the source code of compressible::turbulentHeatFluxTemperature. But when I run the simulation, it shows following error message:
```
Starting time loop
Courant Number mean: 0 max: 0
Time = 2
PIMPLE: iteration 1
--> FOAM FATAL ERROR:
Kappa defined to employ fluidThermo method, but thermo package not available
From function Foam::tmp<Foam::Field<double> > Foam::temperatureCoupledBase::kappa(const scalarField&) const
in file turbulentFluidThermoModels/derivedFvPatchFields/temperatureCoupledBase/temperatureCoupledBase.C at line 142.
FOAM exiting
```
I checked the source code of temperatureCoupledBase.C, the relevant source code associated with this error message is:
```
case mtFluidThermo:
{
typedef compressible::turbulenceModel turbulenceModel;
word turbName(turbulenceModel::propertiesName);
if
(
mesh.foundObject<turbulenceModel>(turbName)
)
{
const turbulenceModel& turbModel =
mesh.lookupObject<turbulenceModel>(turbName);
return turbModel.kappaEff(patchi);
}
else if (mesh.foundObject<fluidThermo>(basicThermo::dictName))
{
const fluidThermo& thermo =
mesh.lookupObject<fluidThermo>(basicThermo::dictName);
return thermo.kappa(patchi);
}
else if (mesh.foundObject<basicThermo>(basicThermo::dictName))
{
const basicThermo& thermo =
mesh.lookupObject<basicThermo>(basicThermo::dictName);
return thermo.kappa(patchi);
}
else
{
FatalErrorInFunction
<< "Kappa defined to employ " << KMethodTypeNames_[method_]
<< " method, but thermo package not available"
<< exit(FatalError);
}
break;
}
```
The lines of code after the first if statement suggests that the this BC will look into the turbulenceProperties dictionary at the constant directory. Then select the turbulence model specified in turbulenceProperties, then evaluate the kappa = kappaEff. So I suppose it will evaluate the kappa automatically rather than jumping to the final error message under the else statement. Please correct me if I understand it wrong.
Therefore, please can you double check it?
Kind regards,
YeruPrashant SonakarPrashant Sonakarhttps://develop.openfoam.com/Development/openfoam/-/issues/1070chemkinToFoam not working for the chemical mechanism format from latest Chemk...2021-11-15T18:37:19ZAdminchemkinToFoam not working for the chemical mechanism format from latest Chemkin VersionHello,
We recently would like to convert chemical mechanism to OpenFOAM format. However, for some chemical mechanisms, they have the information about "PLOG" in the mechanism file. They are used to identify the kinetic parameters for s...Hello,
We recently would like to convert chemical mechanism to OpenFOAM format. However, for some chemical mechanisms, they have the information about "PLOG" in the mechanism file. They are used to identify the kinetic parameters for some special pressure conditions (see attached image). Because of them, the conversion failed. The error information has been attached in this email.
The Openfoam we are using is 5.0 version. Do you have comments about how to resolve this issue if we still would like to use chemkinToFoam.
![20181113131347](/uploads/8a4968f9b269e6f26c6d4ca661c311a8/20181113131347.png)
![20181113131337](/uploads/1f7e08e3bc2c10803e6ca338bbcd9542/20181113131337.png)
![20181113131327](/uploads/a941ebcf1be9bc4fd28ba0f148f231e6/20181113131327.png)https://develop.openfoam.com/Development/openfoam/-/issues/979Doxygen doc includes full paths2018-09-11T14:30:47ZAdminDoxygen doc includes full pathsThe online doxygen doc includes full instead of relative paths, quite possibly from @andy's local environment.
For example see:
https://www.openfoam.com/documentation/cpp-guide/html/ops_8H.htmlThe online doxygen doc includes full instead of relative paths, quite possibly from @andy's local environment.
For example see:
https://www.openfoam.com/documentation/cpp-guide/html/ops_8H.htmlhttps://develop.openfoam.com/Development/openfoam/-/issues/1108turbulentDFSEMInlet; Removal of 'mapMethod' causes FOAM FATAL IO ERROR2019-12-09T16:01:26ZKutalmış BerçinturbulentDFSEMInlet; Removal of 'mapMethod' causes FOAM FATAL IO ERROR### Summary
When `mapMethod` option of `turbulentDFSEMInlet` BC is removed, it raises `FOAM FATAL IO ERROR` although under `turbulentDFSEMInletFvPatchVectorField.H` was stated for its usage was stated to be optional:
Property ...### Summary
When `mapMethod` option of `turbulentDFSEMInlet` BC is removed, it raises `FOAM FATAL IO ERROR` although under `turbulentDFSEMInletFvPatchVectorField.H` was stated for its usage was stated to be optional:
Property | Description | Required | Default value
mapMethod | Method to map reference values | no | planarInterpolation
```
--> FOAM FATAL IO ERROR:
'mapMethod' not found in dictionary "/home/snoopy2/kuta/OpenFOAM/kuta-v1806/run/channel395DFSEM/0/U.boundaryField.inlet"
file: /home/snoopy2/kuta/OpenFOAM/kuta-v1806/run/channel395DFSEM/0/U.boundaryField.inlet
From function const Foam::entry& Foam::dictionary::lookupEntry(const Foam::word&, bool, bool) const
in file db/dictionary/dictionary.C at line 332.
FOAM exiting
```
### Steps to reproduce
Please consider `tutorials/incompressible/pimpleFoam/LES/channel395DFSEM` case.
Remove `mapMethod` under `0/U`:
```
inlet
{
type turbulentDFSEMInlet;
...
mapMethod nearestCell;
...
}
```
to
```
inlet
{
type turbulentDFSEMInlet;
...
}
```
Then execute the following respectively:
`blockMesh`
`decomposePar`
### What is the expected *correct* behavior?
Either the documentation in `turbulentDFSEMInletFvPatchVectorField.H` should be corrected, or the method according to the documentation.v1906Kutalmış BerçinKutalmış Berçin