Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-07-22T11:05:07Zhttps://develop.openfoam.com/Development/ThirdParty-common/-/issues/48Compilation of paraview5.6.3 does not start.2020-07-22T11:05:07Zsariew8Compilation of paraview5.6.3 does not start.$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?$ ~/OpenFOAM/ThirdParty-common$ ./makeParaView \
./makeParaView: 64: local: -DWM_DP: bad variable name \
./makeParaView: 64: ./makeParaView: -DOPENFOAM: bad variable name
did i make another mistakes?Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1530chtMultiRegionTwoPhaseEulerFoam: missing L parameters for restart2020-01-21T20:24:12ZPawan GhildiyalchtMultiRegionTwoPhaseEulerFoam: missing L parameters for restartI) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFo...I) Restarting the case from solution , ask for missing parameters L from Bromley model .
2)Switching the DebugSwitches i.e below one to 2 , lead solver failing with error. Please check with tutorial for
chtMultiRegionTwoPhaseEulerFoam
DebugSwitches
{
compressible::alphatWallBoilingWallFunction 2;
} Sergio FerrarisSergio Ferrarishttps://develop.openfoam.com/Development/openfoam/-/issues/1529foamFormatConvert in parallel does miss converting faces file2019-12-23T14:48:52ZPrashant SonakarfoamFormatConvert in parallel does miss converting faces file### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -file...### Summary
foamFormatConvert to convert between uncollated and collated format fails
### Steps to reproduce
- any case
- set writeFormat binary
- decomposePar -fileHandler uncollated
- mpirun -np XXX foamFormatConvert -parallel -fileHandler collated
This misses out converting the faces file!Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1528snappyHexMesh castellation step creates gaps between curved triangulated surf...2024-01-02T13:17:31ZDries AllaertssnappyHexMesh castellation step creates gaps between curved triangulated surfaces### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, eve...### Summary
In multiRegion cases, the castellation step of snappyHexMesh creates small gaps between curved triangulated surfaces (specified by stl files exported from CAD software AutoDesk Invecntor) when they are not exactly equal, even when stl files are exported at very high resolution (highest resolution available in the CAD software).
### Steps to reproduce
The issue can be reproduced by applying snappyHexMesh on a multiregion case with a curved interface between two regions, and with the different regions specified by different stl files exported from CAD software.
### Example case
Attached is a minimal working example consisting of two concentric cylinders corresponding to a fluid and a solid region. Only the castellation step of snappyHexMesh is run. [MWE.tar.gz](/uploads/21ca31e1c36f1f0e4a2673ec786c5fd9/MWE.tar.gz)
### What is the current *bug* behaviour?
The castellation step of snappyHexMesh creates small gaps between two triangulated surfaces, i.e., on the interface between two regions. As a result, some faces on the interface are identified as walls instead of mappedWalls between the two surfaces. In the snapping step, the gaps are closed but the patch type of some faces remains wall instead of mappedWall.
### What is the expected *correct* behavior?
snappyHexMesh should not remove cells located between two triangulated surface when the two triangulated surfaces coincide within a certain tolerance. The tolerance should be such that coinciding surfaces exported by CAD software can be meshed without creating small gaps. Possibly, this tolerance could be a user input.
### Relevant logs and/or images
Attached is a log file ([log.txt](/uploads/d20cb17863dbfce7ae643e6f8d23c929/log.txt)) of the provided minimal working example (logs of surfaceFeatureExtract - blockMesh - snappyHexMesh - splitMeshRegions) as well as some figures showing the case setup and the gaps on the interface.
Overview of the multiRegion geometry.
![MWE_fig1](/uploads/46a8588961f77c7616bdefac7eede9f1/MWE_fig1.png)
Detailed view of the interface.
![MWE_fig2](/uploads/a691486b653b0a97414885d0052784e1/MWE_fig2.png)
View of the interface, showing some faces that are identified as type wall (white) instead of mappedWall (red)
![MWE_fig3](/uploads/d6a1e6157024dad044c6cc8306f2dd6c/MWE_fig3.png)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : CentOS Linux release 7.6.1810
- Hardware info :
- Compiler : intel
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/1526no fvMesh::solve forwarding for sphericalTensor2019-12-23T14:48:52ZMark OLESENno fvMesh::solve forwarding for sphericalTensor- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642- seen on https://www.cfd-online.com/Forums/openfoam-programming-development/222893-port-of60-of1812-problem.html#post752642https://develop.openfoam.com/Development/openfoam/-/issues/1524Support Loader/Unloader function for libraries2021-07-07T07:23:37ZMark OLESENSupport Loader/Unloader function for librariesIn discussion with @Lars (and others), to forcibly trigger an unload function prior to closing a library. Uses a framework similar to codedBase
[dlLibraryTable.patch](/uploads/6f378c49daf335fae78122e93212c957/dlLibraryTable.patch)
Cross...In discussion with @Lars (and others), to forcibly trigger an unload function prior to closing a library. Uses a framework similar to codedBase
[dlLibraryTable.patch](/uploads/6f378c49daf335fae78122e93212c957/dlLibraryTable.patch)
Cross-ref EP1197.
Patch from Bram.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1523Generate distance to surface for checking correspondence of generated mesh to...2019-12-23T14:48:52ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comGenerate distance to surface for checking correspondence of generated mesh to original surface### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh users### Functionality to add/problem to solve
Would be nice to show the distance from face centres to the geometry that the mesh was generated for.
### Target audience
E.g. snappyHexMesh usersMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1521IListStream scope issue with Foam::List2023-03-01T15:00:46ZOliver PerksIListStream scope issue with Foam::List<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be ...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
You can see how your report will be rendered on the platform by using the
"preview" tab above
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
Scope issue with List in `IListStream.H`.
Whilst testing a new compiler release we encountered a build issue with `IListStream.H`, line 161.
The use of `List<char>&& buffer,` tries to inherit `List<char>` from `Detail::IListStreamAllocator`. However, this is a private member, and so can not be used. I believe the correct usage should be of `Foam::list`.
I have raised this with our internal compiler team, and they believe this to be a code issue rather than a compiler issue.
I believe this relates the the issue shown https://stackoverflow.com/questions/41595208/accessing-the-name-of-a-private-inherited-class-from-a-subclass
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
This issue was encountered when building OpenFOAM 1906 with the Arm Compiler for Linux 20.0 (LLVM 9 based). So I believe this to be an issue for Clang 9.
Simply building with the new compiler 20.0 encountered this issue - as LLVM 9 is being stricter. This was not an issue with the previous version 19.3 (LLVM 7 based) - nor GCC.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
I have reduced the relevant files to the included MWE.
[List_20.0.tar.gz](/uploads/56f54641ce09b4bc4ac35c82c715acf5/List_20.0.tar.gz)
```
> clang++ -std=c++11 -mcpu=native -Wall -Wextra -Wold-style-cast -Wnon-virtual-dtor -Wno-unused-parameter -Wno-invalid-offsetof -Wno-undefined-var-template -Wno-unknown-warning-option -O3 -I. -fPIC -c reproducer.C
In file included from reproducer.C:1:
./IListStream.H:103:10: error: 'List' is a private member of 'Foam::List<char>'
List<char>&& buffer
^
./IListStream.H:61:5: note: constrained by private inheritance here
private List<char>
^~~~~~~~~~~~~~~~~~
./List.H:65:7: note: member is declared here
class List
^
1 error generated.
```
### What is the current *bug* behaviour?
<!-- What actually happens -->
As shown above, the attempt is made to scope `List<char>` from the wrong source - `IListStreamAllocator`.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
`List<char>` should be sourced from `List.H`.
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1906
- Operating system : RHEL 7 + 8
- Hardware info : Arm (aarch64)
- Compiler : clang 9 (armclang from Arm Compiler for Linux 20.0)
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
The "/label ~bug" text is a gitlab flag that will add the "bug" label to this
issue
-->
https://develop.openfoam.com/Development/openfoam/blob/master/src/OpenFOAM/db/IOstreams/memory/IListStream.H#L161
Before:
`List<char>&& buffer,`
After:
`Foam::List<char>&& buffer,`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1519cell derminant in checkMesh too limiting2021-07-06T16:39:04ZPrashant Sonakarcell derminant in checkMesh too limiting### Functionality to add/problem to solve
For low-Re meshes, the high aspect ratio might trigger the cell determinant warning.
The cell determinant
- is a measure for how close the cell is to an ideal 'cube' shape.
- it does a principa...### Functionality to add/problem to solve
For low-Re meshes, the high aspect ratio might trigger the cell determinant warning.
The cell determinant
- is a measure for how close the cell is to an ideal 'cube' shape.
- it does a principal axis determination based on amount of face-area (to internal faces)
- the determinant is then the product of the face-areas in all three principal directions
For high-aspect ratio cells or indeed 1D pipes the cell determinant is very small or zero. It probably should not look at the determinant but instead make sure there is at least one 'valid' direction (enough connectivity to neighbouring cells).
This is more a problem of what we want to output than problems with the mesh or checkMesh.
The problem is that in the default `meshQualityDict` in etc/caseDicts specifies a minimum cellDeterminant of 0.001. Maybe this needs reviewing.https://develop.openfoam.com/Development/openfoam/-/issues/1518BUG: no regression in tutorials using potentialFoam due to the lack of -writephi2019-12-12T11:33:12ZKutalmış BerçinBUG: no regression in tutorials using potentialFoam due to the lack of -writephi[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option ...[New `writephi` option](https://develop.openfoam.com/Development/openfoam/blob/develop/applications/solvers/basic/potentialFoam/potentialFoam.C#L200) of `potentialFoam` was default in previous versions (<= 1906).
The lack of new option throughout tutorials will lead to different results from tutorials.
Adding `-writephi` option into the `Allrun` scripts where `potentialFoam` is present could be the solution.Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1516blockMesh be able to generate duplicate patches (e.g. cyclicACMI + wall)2021-07-06T16:37:59ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comblockMesh be able to generate duplicate patches (e.g. cyclicACMI + wall)### Functionality to add/problem to solve
Currently ACMI cases have to have additional patches added (to get the duplicate cyclicACMI + wall patches). Be nice if this could be done inside blockMesh.
### Target audience
blockMesh meshe...### Functionality to add/problem to solve
Currently ACMI cases have to have additional patches added (to get the duplicate cyclicACMI + wall patches). Be nice if this could be done inside blockMesh.
### Target audience
blockMesh meshes with cyclicACMI. Be much harder to add to any topo changing (e.g. snappyHexMesh). This would need to add the concept of duplicate baffles to polyMesh.
The blockMesh route uses the 'construct-from-cellShape' route. Attached a hack to get hold of the patch when doing the blockMesh. This could check for cyclicACMI and allow duplicate block faces (or just give a warning instead of falling over)
[polyMeshFromShapeMesh.C](/uploads/991ad5e38fccf5b3949b44335a879ac0/polyMeshFromShapeMesh.C)https://develop.openfoam.com/Development/openfoam/-/issues/1515compilation failure of libs POSIX (latest version Dec 2019, PLUS)2019-12-26T08:48:56Zsariew8compilation failure of libs POSIX (latest version Dec 2019, PLUS)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)i failed to install the latest version (openfoam-plus) in POSIX library. Where should i fix them?
---
[log.make.tar.gz](/uploads/e044e9a16a178ec32a70dce26771523d/log.make.tar.gz)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1291In the same case, magneticFoam in this version does not return any results.2019-07-09T18:06:00ZAdminIn the same case, magneticFoam in this version does not return any results.<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
'magneticFoam' in this version does not return any results but ofv6 seems to work properly for it.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
we execute 'Allrun' script in the case.
### Example case
<!--
If possible, please create a SMALL example and attach it to your report
If you are using an older version of OpenFOAM this will also determine
whether the bug has been fixed in a more recent version
-->
for v1812[magSandboxFailure.zip](/uploads/a40f6c4e3576f97e1f4c4da61c935038/magSandboxFailure.zip)
---
for ofv6[magSandboxSuccess.zip](/uploads/7f2544852e5e54e233f4f2e41f6d0f7d/magSandboxSuccess.zip)
### What is the current *bug* behaviour?
<!-- What actually happens -->
--> FOAM FATAL ERROR:
cannot find file "/home/xxxx/OpenFOAM/xxxx-v1812/run/magSandbox/0/murf"
### What is the expected *correct* behavior?
<!-- What you should see instead -->
### Relevant logs and/or images
<!--
Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code as it's very hard to read otherwise.
-->
[log.zip](/uploads/6f108923bcfe39f2bf404b48bc96b2ae/log.zip)
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1812
Operating system : ubuntu
Hardware info : intel
Compiler : gcc-7.3.0
-->
OpenFOAM version :v1812
Operating system :ubuntu18.04
Compiler :gcc-7.3.0
### Possible fixes
<!--
If you can, link to the line of code that might be responsible for the
problem
-->Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1282dynamicCode does not work with the Intel compiler2023-12-07T19:00:15ZAdmindynamicCode does not work with the Intel compilerIf "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line n...If "blockMesh" is executed in the tutorial $FOAM_TUTORIALS/basic/potentialFoam/cylinder using an OpenFOAM version compiled with the Intel compiler, the following error message will appear:
codeStreamTemplate.C(35): error: invalid line number
#line 0 "/path/to/system/blockMeshDict.#codeStream"
I tested this with Intel2018 and 2019 and OpenFOAM v1712 and v1812 on two different systems and the error happens with all instances where dynamicCode is used.
The generated code in cylinder/dynamicCode/_1c19e29ae18c779aa836a14631d6419f303e3d9d/codeStreamTemplate.C in line 35 reads:
#line 0 "/path/to/cylinder/system/blockMeshDict.#codeStream"
The Intel compiler complains about the "0". If instead "blockMesh" is run with an OpenFOAM version compiled with clang or gcc, the same code is generated but the compiler does not complain. A quick fix would be to remove the following line:
https://develop.openfoam.com/Development/OpenFOAM-plus/blob/master/src/OpenFOAM/db/dynamicLibrary/dynamicCode/dynamicCodeContext.C#L129Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1284dry-run-write overwrites mesh2019-04-15T09:58:33ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comdry-run-write overwrites mesh<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
<!-- Summarize the bug encountered concisely -->
dry-run-write overwrites mesh with the dry-run write.Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1256Extracting used compiler flags2020-05-06T15:23:09ZAdminExtracting used compiler flags### Functionality to add/problem to solve
When compiling third-party applications that are to be used together with OpenFOAM it is reasonable to use the same compiler flags as `wmake` does. To provide a concrete example, I want to compi...### Functionality to add/problem to solve
When compiling third-party applications that are to be used together with OpenFOAM it is reasonable to use the same compiler flags as `wmake` does. To provide a concrete example, I want to compile Google Test using `wmake` flags. Sourceflux provides a tutorial on that, see refs, where they use a pretty simple python script to extract the compiler flags. The script doesn't work with OpenFOAM-plus, however, because the flags are spread across multiple files and imported using includes in the rule-file.
### Target audience
Developers looking to compile third-party applications with the same compiler flags as OpenFOAM
### Proposal
There is a $WM_CXXFLAGS variable defined, but it doesn't contain the warning flags. I could not find a variable containing all the flags. Perhaps, such a variable could be created?
### What does success look like, and how can we measure that?
An easy way to obtain all the compiler flags.
### Links / references
https://sourceflux.de/blog/google-test-and-openfoamMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/542failed check for scotch header2017-07-20T10:00:40ZMark OLESENfailed check for scotch headerSystem scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19System scotch can be located under `/usr/include/scotch/scotch.h`
- Was originally logged under ThirdParty https://develop.openfoam.com/Development/ThirdParty-plus/issues/19Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/116coupled edge synchronisation on cyclic baffles2016-06-13T13:40:18ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comcoupled edge synchronisation on cyclic bafflesCoupled edge handling was not correct for cyclic baffles. This gives some obscure error message about not being able to find transform.
This is solved in Foundation dev 001e172fed1d4ef231fce4f6f94439df86bb0fcf. If it doesn't give any...Coupled edge handling was not correct for cyclic baffles. This gives some obscure error message about not being able to find transform.
This is solved in Foundation dev 001e172fed1d4ef231fce4f6f94439df86bb0fcf. If it doesn't give any problems we might want to merge this in early (i.e. before the next big re-sync)
https://develop.openfoam.com/Development/openfoam/-/issues/78Request for a FAQ section on the Windows page2016-04-19T08:17:38ZAdminRequest for a FAQ section on the Windows pageAlthough the page on the [binary packages for Docker](http://openfoam.com/download/install-binary.php) has a FAQ section, the [one for Windows](http://openfoam.com/download/install-windows.php) currently does not :(
I'm asking you for...Although the page on the [binary packages for Docker](http://openfoam.com/download/install-binary.php) has a FAQ section, the [one for Windows](http://openfoam.com/download/install-windows.php) currently does not :(
I'm asking you for this here and not via email, given that this is more of a website-related issue than the project for the deployments of OpenFOAM+ with Docker (which would be nice to have one here in your Gitlab hub).
In addition, as a moderator on the CFD-Online forums, I've moved most of the threads on installation issues about OpenFOAM+ 3.0+ to the main [OpenFOAM installation forum](http://www.cfd-online.com/Forums/openfoam-installation/) - since OpenFOAM+ supports installation on Windows - and most of those threads currently have the prefix "[OpenFOAM plus]" to make it easier to spot them, simply by searching for `[OpenFOAM plus]` on this (sub)forum.
One thread in particular is what has lead me to create this bug report/feature request: [[OpenFOAM plus][3.0+] on Windows ---- How do I run tutorials?](http://www.cfd-online.com/Forums/openfoam-installation/165439-openfoam-plus-3-0-windows-how-do-i-run-tutorials.html)
Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/1226BUG: dict.lookupOrDefault<label> throws FATAL IO Error for E-notation number ...2019-04-01T15:22:34ZKutalmış BerçinBUG: dict.lookupOrDefault<label> throws FATAL IO Error for E-notation number dict entry, but not for the same default value<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these marker...<!--
*** Please read this first! ***
Before opening a new issue, make sure to search for keywords in the issues
filtered by the "bug" label and check to see if it has already been reported
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
Say the following `functionObject` exists with two `optional` entries which accept `label` types as input:
```
functions
{
iAmFunctionObject
{
...
aSmallInteger -1e9;
aLargeInteger 1e9;
}
```
The `label` objects, i.e. `aSmallInteger` and `aLargeInteger`, are initialised in `iAmFunctionObject`'s constructor via:
```
iAmIntegerRange_
(
labelRange
(
dict.lookupOrDefault<label>("aSmallInteger", -1),
dict.lookupOrDefault<label>("aLargeInteger", 1e9)
)
),
```
* When these optional entries are not present under `controlDict\functions\iAmFunctionObject`: No FATAL IO ERROR occurs.
* When such an optional entry is present under `controlDict\functions\iAmFunctionObject`: The following is thrown:
```
--> FOAM FATAL IO ERROR:
Wrong token type - expected label (int32), found on line 59: double 1000000000
```
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
I can only provide a Minimal Working Example after the completion of the relevant functionObject, I am afraid.
### What is NOT the *bug*?
The following does not throw an IO Error:
```
functions
{
iAmFunctionObject
{
...
aSmallInteger -1000000000;
aLargeInteger 1000000000;
}
```
### What is the expected *correct* behavior?
1. IMHO, this behaviour is inconsistent (yet might not be important as well) since one can input `1e9` as `label` when the object is default initialised; (that is `dict.lookupOrDefault<label>("aLargeInteger", 1e9)`), but not through a dictionary entry.
2. In addition, a user might expect for that any E-notation without a decimal point, e.g. `1e4` or `-5e8`, the type deduction will be `label` rather than `scalar`. However, it is also legitimate to throw such type deduction error for E-notations with decimal points, e.g. `1.0e4` or `1.3e4`.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1806|v1812|v1906 etc
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
OpenFOAM version : v1812
Operating system : openSUSE
Compiler : gcc