Development issueshttps://develop.openfoam.com/groups/Development/-/issues2020-09-29T10:27:16Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1835faMatrix residual changes source?2020-09-29T10:27:16ZMark OLESENfaMatrix residual changes source?by inspection (noticed while examining #1834). The faMatrix::residual has this code:
```
tmp<Field<Type>> tres(source_);
Field<Type>& res = tres().ref();
```
which implies that calculating the residual affects the source vector.
Probab...by inspection (noticed while examining #1834). The faMatrix::residual has this code:
```
tmp<Field<Type>> tres(source_);
Field<Type>& res = tres().ref();
```
which implies that calculating the residual affects the source vector.
Probably should be
```
tmp<Field<Type>> tres(new Field<Type>>(source_);
Field<Type>& res = tres().ref();
```
@andyMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/545Problem with BC for upwind discretization causing oscillating/negative soluti...2020-10-02T23:27:10ZAdminProblem with BC for upwind discretization causing oscillating/negative solution (tested in 1D scalarTransportFoam)As described here
https://www.cfd-online.com/Forums/openfoam-bugs/188749-negative-values-scalartransportfoam-upwind-discretization.html
the usage of upwind discretization does not prevent the appearance of oscillations in the scalar fiel...As described here
https://www.cfd-online.com/Forums/openfoam-bugs/188749-negative-values-scalartransportfoam-upwind-discretization.html
the usage of upwind discretization does not prevent the appearance of oscillations in the scalar field with scalarTransportFoam in the standard 1D convection-diffusion test case (i.e. T(0)=0 and T(L)=1 with advection dominated flow), where the region with the high gradient is located directly at the x=L boundary.
If the gradient is located in the volume (by adding a volume source term for T vie the fvOptions and setting the BC at x=L to zeroGradient), the upwind discretization behaves as expected, giving a smooth (overly-diffusive) solution over the entire volume. This points to a problem with the boundary conditions.
\## Reattaching the author to the issue ticket: @Mesl ##https://develop.openfoam.com/Development/openfoam/-/issues/1679collated fileHandler does not adjust timePrecision2020-10-04T19:58:13ZTimofey Mukhacollated fileHandler does not adjust timePrecision<!--
*** 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
Unlike the uncollated filehandler, the collated one does not adjust the timePrecision value to be able to read the time directory.
Instead, it just crashes the run.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
- Grab pretty much any tutorial case, I took pitzDaily.
- Replace the 0 directory with something like 0.1234567
- Change the file handler to collated in the controlDict, and timePrecision to something small, like 3.
- Decompose and run, it will crash.
Note that the decomposition works, and you will see the warning about adjusting timePrecision. But the solver will crash.
### What is the expected *correct* behavior?
That the timePrecision is adjusted, or at least crash with a clear error message.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: v1912 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _f3950763fe-20191219 OPENFOAM=1912
Arch : "LSB;label=32;scalar=64"
Exec : simpleFoam -parallel
Date : Apr 13 2020
Time : 12:19:08
Host : DESKTOP-MPTRIAD
PID : 1600
I/O : uncollated
Case : /mnt/c/Users/tiamm/OpenFOAM/timofey-v1912/run/tests/pitzDaily
nProcs : 2
Hosts :
(
(DESKTOP-MPTRIAD 2)
)
Pstream initialized with:
floatTransfer : 0
nProcsSimpleSum : 0
commsType : nonBlocking
polling iterations : 0
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 10)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Overriding OptimisationSwitches according to controlDict
fileHandler (unregistered)
Overriding fileHandler to collated
I/O : collated (maxThreadFileBufferSize 0)
Threading not activated since maxThreadFileBufferSize = 0.
Writing may run slowly for large file sizes.
Create mesh for time = 0.123
SIMPLE: convergence criteria
field p tolerance 0.01
field U tolerance 0.001
field "(k|epsilon|omega|f|v2)" tolerance 0.001
Reading field p
--------------------------------------------------------------------------
MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
with errorcode 1.
NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
You may or may not see output from other processes, depending on
exactly when Open MPI kills them.
--------------------------------------------------------------------------
[0]
[0]
[0] --> FOAM FATAL IO ERROR:
[0] cannot find file "/mnt/c/Users/tiamm/OpenFOAM/timofey-v1912/run/tests/pitzDaily/processor0/0.123/p"
[0]
[0] From function static Foam::autoPtr<Foam::ISstream> Foam::fileOperations::masterUncollatedFileOperation::read(Foam::IOobject&, Foam::label, bool, const fileNameList&, const boolList&)
[0] in file global/fileOperations/masterUncollatedFileOperation/masterUncollatedFileOperation.C at line 617.
[0]
FOAM parallel run exiting
[0]
```
Note that the error message is also confusing because it searches in processor0, which is not something one expects from the collated fileHandler. Easy to miss the fact that the time directory is wrong in a more practical case.
### Environment information
<!--
Providing details of your set-up can help us identify any issues, e.g.
OpenFOAM version : v1912
Operating system : ubuntu|openSUSE|centos etc
Hardware info : any info that may help?
Compiler : gcc|intel|clang etc
-->
- OpenFOAM version : v1912Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1597v1912 over*DyMFoam tutorials fail on multi-node parallel2020-10-06T21:23:24ZGreg Burgreenv1912 over*DyMFoam tutorials fail on multi-node parallelDo the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel...Do the v1912 tutorial cases overInterDyMFoam/floatingBody and overPimpleDyMFoam/simpleRotor work for you guys for a multi-node parallel run?
They both work fine for me serial and on a single parallel node. Once I try multi-node parallel processing, I am getting either scrambled garbage for the field variables (floatingBody) or returns segFault or sigFpe on a random iteration (simpleRotor). It appears that data is not being properly transferred across compute nodes.
I am using Scotch decomposition and OpenMPI-4.0.0.
```
PIMPLE: iteration 1
[2] [5] #0 #0 Foam::error::printStack(Foam::Ostream&)Foam::error::printStack(Foam::Ostream&) at at ??:?
[2] #1 Foam::sigFpe::sigHandler(int)??:?
[5] #1 Foam::sigFpe::sigHandler(int) at ??:?
[2] #2 ? at ??:?
[5] #2 ? in /lib64/libc.so.6
[2] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) in /lib64/libc.so.6
[5] #3 Foam::divide(Foam::Field<double>&, double const&, Foam::UList<double> const&) at ??:?
[2] #4 void Foam::divide<Foam::fvPatchField, Foam::volMesh>(Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh>&, Foam::dimensioned<double> const&, Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> const&) at ??:?
[5] #4 at ??:?
```v2006Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1863CompactListList transfer leaves old size2020-10-07T19:20:16ZMark OLESENCompactListList transfer leaves old sizeMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1870no match for argument: openfoam2006-default2020-10-08T06:15:26ZAndrig T Millerno match for argument: openfoam2006-default<!--
*** 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 re...<!--
*** 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 -->
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
### 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.
-->
### 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 :2006
- Operating system :Fedora 32
- Hardware info :AMD Ryzen 9 (3900 12 core)
- Compiler :N/A
### 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
-->
I'm not sure I should enter this, but I couldn't find any other way to contact someone that might be able to help. I enabled the copr repo openfoam/openfoam on Fedora 32, and then tried to install openfoam2006-default, as the wiki shows, but I get the following error:
no match for argument:openfoam2006-default
I tried others like openfoam, and openfoam-devel, but it can't find the packages. I have verified that the repo is enabled, but nothing.
Anyone know what's going on? I would love to put openfoam to use, but can't get it installed from the repo.https://develop.openfoam.com/Development/openfoam/-/issues/1873foamToEnsight lagrangian fails in parallel2020-10-12T11:50:47ZMark OLESENfoamToEnsight lagrangian fails in parallel- as noted in EP1406 (@Prashant), converting Lagrangian fields in parallel fails for some simulations. Converting to VTK works without issue.- as noted in EP1406 (@Prashant), converting Lagrangian fields in parallel fails for some simulations. Converting to VTK works without issue.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1864mapPolyMesh constructor from mesh incorrect2020-10-12T11:50:47ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.commapPolyMesh constructor from mesh incorrectMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1877ptscotch not found on arch linux2020-10-12T11:50:47ZMark OLESENptscotch not found on arch linuxMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1878add face::copyFace method2020-10-13T12:30:50ZMark OLESENadd face::copyFace methodIdea to replace some repetitive code that occurs when collecting faces from various processors (for example).
Existing code:
```
for (const face& f : allFaces[Pstream::myProcNo()])
{
face& newF = faces[nFaces++];
newF.resize(f.s...Idea to replace some repetitive code that occurs when collecting faces from various processors (for example).
Existing code:
```
for (const face& f : allFaces[Pstream::myProcNo()])
{
face& newF = faces[nFaces++];
newF.resize(f.size());
forAll(f, fp)
{
newF[fp] = f[fp] + nPoints;
}
}
```
With the definition:
```
//- Return a copy of the face with given offset of its labels
inline face copyFace(const label offset) const;
```
This would simplify:
```
for (const face& f : allFaces[Pstream::myProcNo()])
{
faces[nFaces] = f.copyFace(nPoints);
++nFaces;
}
```
Naming similarity to `reverseFace()`Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/73No repository for Dockerfile2020-10-20T15:23:29ZAdminNo repository for DockerfileThere should be one, that's linked to Docker Hub. I would like to make some improvements to the Docker ecosystem.There should be one, that's linked to Docker Hub. I would like to make some improvements to the Docker ecosystem.Pawan GhildiyalPawan Ghildiyalhttps://develop.openfoam.com/Development/openfoam/-/issues/639cleanup autoPtr, tmp, xfer2020-10-20T16:23:38ZMark OLESENcleanup autoPtr, tmp, xfer- Some constructors and methods can be constexpr, noexcept.
- most places have a const copy constructor that steals the contents. Could/should be revised to use a universal reference and prohibit const copy (as per std::unique_ptr).- Some constructors and methods can be constexpr, noexcept.
- most places have a const copy constructor that steals the contents. Could/should be revised to use a universal reference and prohibit const copy (as per std::unique_ptr).v1806Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1879construct token::compound from object2020-10-21T14:51:02ZMark OLESENconstruct token::compound from object@Mattijs@MattijsMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1890Clearly mark Allrun scripts etc that use bash2020-10-23T15:35:21ZPetros AmpatzidisClearly mark Allrun scripts etc that use bashWhen I try to run the `Allrun` script in the new `$FOAM_TUTORIALS/verificationAndValidation/atmosphericModels/atmForestStability` tutorial case in v2006 I get:
```
./Allrun: 13: ./Allrun: declare: not found
./Allrun: 14: ./Allrun: decla...When I try to run the `Allrun` script in the new `$FOAM_TUTORIALS/verificationAndValidation/atmosphericModels/atmForestStability` tutorial case in v2006 I get:
```
./Allrun: 13: ./Allrun: declare: not found
./Allrun: 14: ./Allrun: declare: not found
./Allrun: 15: ./Allrun: declare: not found
./Allrun: 17: ./Allrun: stabilityStates[0]=veryStable: not found
./Allrun: 18: ./Allrun: stabilityStates[1]=stable: not found
./Allrun: 19: ./Allrun: stabilityStates[2]=slightlyStable: not found
./Allrun: 20: ./Allrun: stabilityStates[3]=neutral: not found
./Allrun: 21: ./Allrun: stabilityStates[4]=slightlyUnstable: not found
./Allrun: 22: ./Allrun: stabilityStates[5]=unstable: not found
./Allrun: 24: ./Allrun: Lmaxs[0]=5.0: not found
./Allrun: 25: ./Allrun: Lmaxs[1]=13.0: not found
./Allrun: 26: ./Allrun: Lmaxs[2]=25.5: not found
./Allrun: 27: ./Allrun: Lmaxs[3]=41.0: not found
./Allrun: 28: ./Allrun: Lmaxs[4]=80.75: not found
./Allrun: 29: ./Allrun: Lmaxs[5]=200.0: not found
./Allrun: 31: ./Allrun: qPlants[0]=-20.0: not found
./Allrun: 32: ./Allrun: qPlants[1]=-9.0: not found
./Allrun: 33: ./Allrun: qPlants[2]=-5.0: not found
./Allrun: 34: ./Allrun: qPlants[3]=0.0: not found
./Allrun: 35: ./Allrun: qPlants[4]=15.0: not found
./Allrun: 36: ./Allrun: qPlants[5]=60.0: not found
./Allrun: 39: ./Allrun: Bad substitution
```
It seems that something's wrong with the `declare` command. Do you think it is related to my OpenFOAM installation or is an inherent bug?Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1885foamNewBC incorrect for Function1 member data2020-10-24T09:01:27ZHåkanfoamNewBC incorrect for Function1 member data<!--
*** 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 re...<!--
*** 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
foamNewBC incorrect for Function1 member data. It is not possible to compile the default output.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
foamNewBC -f -v XYZ
wmake XYZ
<!-- How one can reproduce the issue - this is very important -->
### Example case
N/A
<!--
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
-->
### What is the current *bug* behaviour?
Compilation fails
<!-- What actually happens -->
### What is the expected *correct* behavior?
It should compile, so that the user gets a good example from the script.
<!-- 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.
-->
### 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 : v2006
- Operating system : Ubuntu 20.04
- Hardware info :
- Compiler :
### 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
-->
In last three constructors in the initialization (XYZ...C), it should be corrected to (from translatingWallVelocityFvPatchVectorField.C):
timeVsData_(ptf.timeVsData_.clone()),Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1898Macro FatalIOErrorInLookup does not work in surfaceInterpolationScheme.C2020-10-26T16:36:05ZOleg RogozinMacro FatalIOErrorInLookup does not work in surfaceInterpolationScheme.C<!--
*** 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 re...<!--
*** 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
A program does not print a list of available `surfaceInterpolationSchemes` in case of wrong input parameters.
<!-- Summarize the bug encountered concisely -->
### Steps to reproduce
Fill `system/fvSchemes` with
```
divSchemes
{
default Gauss unknown;
}
```
Then, the debug output is as follows:
```
From static Foam::tmp<Foam::fv::divScheme<Type> > Foam::fv::divScheme<Type>::New(const Foam::fvMesh&, Foam::Istream&) [with Type = Foam::Vector<double>]
in file /opt/OpenFOAM/OpenFOAM-v2006/src/finiteVolume/lnInclude/divScheme.C at line 56
Constructing divScheme<Type>
From static Foam::tmp<Foam::surfaceInterpolationScheme<Type> > Foam::surfaceInterpolationScheme<Type>::New(const Foam::fvMesh&, Foam::Istream&) [with Type = Foam::Vector<double>]
in file lnInclude/surfaceInterpolationScheme.C at line 58
Discretisation scheme = unknown
--> FOAM FATAL ERROR:
FOAM exiting
```
<!-- How one can reproduce the issue - this is very important -->
### 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
-->
### What is the current *bug* behaviour?
<!-- What actually happens -->
There is no list of registered schemes.
### What is the expected *correct* behavior?
```
--> FOAM FATAL IO ERROR:
Unknown discretisation scheme unknown
Valid schemes are :
61
(
CoBlended
Gamma
...
```
<!-- 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.
-->
### 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 : newer than v1912
- Operating system :
- Hardware info :
- Compiler :
### Possible fixes
The bug was introduced in [this commit](https://develop.openfoam.com/Development/openfoam/-/commit/fb09f56abac9dcb3e24f243be6172119b6a2148d).
To fix the bug, the following code from [`surfaceInterpolationScheme.C`](https://develop.openfoam.com/Development/openfoam/-/blob/master/src/finiteVolume/interpolation/surfaceInterpolation/surfaceInterpolationScheme/surfaceInterpolationScheme.C)
```c++
FatalIOErrorInLookup
(
schemeData,
"discretisation",
schemeName,
*MeshConstructorTablePtr_
) << exit(FatalError);
```
can be replaced by
```c++
FatalIOErrorInLookup
(
schemeData,
"discretisation",
schemeName,
*MeshConstructorTablePtr_
) << exit(FatalIOError);
```
<!--
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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1882regionToFace not working2020-10-26T16:36:05ZMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comregionToFace not working<!--
*** 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 re...<!--
*** 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 -->
regionToFace does not limit walk so all is assigned a single region
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Happens only in some conditions so hard to reproduce.
### 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
-->
See ep1420Mattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comMattijs Janssens4-Mattijs@users.noreply.develop.openfoam.comhttps://develop.openfoam.com/Development/openfoam/-/issues/1889setExprFields floatingPointException evaluating log of variable2020-10-28T23:15:34ZJoshua DysonsetExprFields floatingPointException evaluating log of variable<!--
*** 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 re...<!--
*** 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 -->
When using an expressing in setExprFields containing log of a variable it exits with a floating point exception.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run setExprFields using a an expression that contains log(variable)
### 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
-->
Modify `tutorials/compressible/rhoPimpleFoam/RAS/TJunctionAverage/system/setExprFieldsDict` so that the expression is:
```
expression
#{
300
+ log(radius)
#};
```
Additionally this also doesn't work:
```
expression
#{
300
+ log(10*radius)
#};
```
However this works correctly:
```
expression
#{
300
+ log(1/radius)
#};
```
### What is the current *bug* behaviour?
<!-- What actually happens -->
Exits with a floating point exception when a strange set of criteria is met.
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The variable is evaluated correctly and the correct field values are applied.
### 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.
-->
```
/*---------------------------------------------------------------------------*\
| ========= | |
| \\ / F ield | OpenFOAM: The Open Source CFD Toolbox |
| \\ / O peration | Version: 2006 |
| \\ / A nd | Website: www.openfoam.com |
| \\/ M anipulation | |
\*---------------------------------------------------------------------------*/
Build : _295eef47-20201012 OPENFOAM=2006 patch=201012
Arch : "LSB;label=32;scalar=64"
Exec : setExprFields
Date : Oct 21 2020
Time : 10:01:35
Host : chimera
PID : 18880
I/O : uncollated
Case : /****/TJunctionAverage
nProcs : 1
trapFpe: Floating point exception trapping enabled (FOAM_SIGFPE).
fileModificationChecking : Monitoring run-time modified files using timeStampMaster (fileModificationSkew 5, maxFileModificationPolls 20)
allowSystemOperations : Allowing user-supplied system call operations
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //
Create time
Create mesh for time = 0
Time = 0
Modify field: T (type volScalarField) time=0
Expression:
>>>>
300
+ log(10*radius)
<<<<
Condition:
>>>>
(mag(pos() - vector(0.21,0,0.01)) < radius)
&& pos((pos() - vector(0.21,0,0.01)).y()) > 0
<<<<
#0 Foam::error::printStack(Foam::Ostream&) at ??:?
#1 Foam::sigFpe::sigHandler(int) at ??:?
#2 ? in /lib64/libpthread.so.0
#3 log in /lib64/libm.so.6
#4 Foam::log(Foam::Field<double>&, Foam::UList<double> const&) at ??:?
#5 Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > Foam::log<Foam::fvPatchField, Foam::volMesh>(Foam::tmp<Foam::GeometricField<double, Foam::fvPatchField, Foam::volMesh> > const&) at ??:?
#6 ? at volumeExprLemonParser.cc:?
#7 Foam::expressions::volumeExpr::parser::parse(int, Foam::expressions::volumeExpr::scanToken*) at ??:?
#8 Foam::expressions::volumeExpr::scanner::process(std::string const&, unsigned long, unsigned long, Foam::expressions::volumeExpr::parseDriver&) at ??:?
#9 Foam::expressions::volumeExpr::parseDriver::parse(std::string const&, unsigned long, unsigned long) at ??:?
#10 ? at ??:?
#11 ? at ??:?
#12 __libc_start_main in /lib64/libc.so.6
#13 ? at ??:?
Floating point exception (core dumped)
```
### 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 : v2006
- Operating system : centoOS 7
- Hardware info : Intel E5-1620, 64GB RAM
- Compiler : gcc 4.8.5
OpenFOAM installed using the yum package manager as described in the release notes.
### 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
-->Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1903orientation information in blockMesh VTK output2020-10-29T08:14:21ZMark OLESENorientation information in blockMesh VTK outputcomment raised via linkedIn, where the person seemed to have incorrectly oriented their blocks and was very confused that the three grid parameters did not correspond to global x/y/z.
Fairly easy to extract this information from the blo...comment raised via linkedIn, where the person seemed to have incorrectly oriented their blocks and was very confused that the three grid parameters did not correspond to global x/y/z.
Fairly easy to extract this information from the blocks and save as fields with `-write-vtk`.
![orientation](/uploads/759c7227a15fb40833040c5f0f2a00c5/orientation.png)Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1896FOAM_ABORT enabled if set to anything.2020-10-29T08:14:45ZMark OLESENFOAM_ABORT enabled if set to anything.For FOAM_SIGFPE and FOAM_SETNAN we use true/false/yes/no/integer to decide on enable or disabled, but for FOAM_ABORT we merely check if it exists.
Thus `FOAM_ABORT=false someApplication` will actually enable abort.
@Mattijs @andyFor FOAM_SIGFPE and FOAM_SETNAN we use true/false/yes/no/integer to decide on enable or disabled, but for FOAM_ABORT we merely check if it exists.
Thus `FOAM_ABORT=false someApplication` will actually enable abort.
@Mattijs @andyMark OLESENMark OLESEN