Development issueshttps://develop.openfoam.com/groups/Development/-/issues2021-12-22T16:31:49Zhttps://develop.openfoam.com/Development/openfoam/-/issues/1888Dockerhub container sources2021-12-22T16:31:49ZGonzaloDockerhub container sourcesI am not able to find the source files used to create the containers published to dockerhub. Are these available somewhere?
In #73 this same issue was closed suggesting that the sources are available in the Snippets, but this does not ...I am not able to find the source files used to create the containers published to dockerhub. Are these available somewhere?
In #73 this same issue was closed suggesting that the sources are available in the Snippets, but this does not appear to be the case anymore (or at least, I cannot find them).
Also, that issue is about it being good practice to link the docker container sources to the dockerhub repository, so that those wanting to inspect what is actually in the container can quickly do so. This is currently not the case.https://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/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/1891handle out-of-range surface sampling2021-12-10T13:16:03ZMark OLESENhandle out-of-range surface samplingIssue raised on EP974. When sampling onto a meshed surface, we have the possibility of using `cells`, `insideCells`, `boundaryFaces`. However, when using `cells` (for example), it takes the closest cell. If sampling surface happens to be...Issue raised on EP974. When sampling onto a meshed surface, we have the possibility of using `cells`, `insideCells`, `boundaryFaces`. However, when using `cells` (for example), it takes the closest cell. If sampling surface happens to be out of the domain, for example since it extends into various mesh regions, the value of the closest cell will be wildly incorrect and misleading.
The proposed solution is to add in support for specifying a max search radius and a default value.
For example,
```
maxSearch 0.005;
defaultValues
{
"p.*" 0;
T 273.15;
U (-100 -100 -100);
...
}
```
Note that sampling onto a meshed surface is the only surface sampler that this affects.Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1893Installing on Fedora 32: dnf conflicting requests - nothing provides libmpi.s...2020-11-26T01:16:19ZPhilipInstalling on Fedora 32: dnf conflicting requests - nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64This is different than the closed https://develop.openfoam.com/Development/openfoam/-/issues/1815
### Summary
<!-- Summarize the bug encountered concisely -->
dnf install openfoam2006 # FAILS! With
```
Error:
Problem: conflicting re...This is different than the closed https://develop.openfoam.com/Development/openfoam/-/issues/1815
### Summary
<!-- Summarize the bug encountered concisely -->
dnf install openfoam2006 # FAILS! With
```
Error:
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
Note that libmpi.so.40 exists in /usr/lib64/openmpi/lib/
ll /usr/lib64/openmpi/lib/libmpi.so*
lrwxrwxrwx. 1 root root 17 Jun 18 11:49 /usr/lib64/openmpi/lib/libmpi.so -> libmpi.so.40.20.4
lrwxrwxrwx. 1 root root 17 Jun 18 11:49 /usr/lib64/openmpi/lib/libmpi.so.40 -> libmpi.so.40.20.4
-rwxr-xr-x. 1 root root 1169088 Jun 18 11:50 /usr/lib64/openmpi/lib/libmpi.so.40.20.4
```
### Steps to reproduce
dnf copr enable openfoam/openfoam
dnf install openfoam2006
dnf install openfoam2006 --skip-broken
### Example case
see above.
### What is the current *bug* behaviour?
<!-- What actually happens -->
```
# dnf install openfoam2006 # CFD OpenFOAM
Last metadata expiration check: 0:59:38 ago on Thu 22 Oct 2020 05:09:25 PM HKT.
Error:
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
(try to add '--skip-broken' to skip uninstallable packages)
# dnf install openfoam2006 --skip-broken # CFD OpenFOAM
Last metadata expiration check: 0:51:03 ago on Thu 22 Oct 2020 05:09:25 PM HKT.
Dependencies resolved.
Problem: conflicting requests
- nothing provides libmpi.so.40()(64bit) needed by openfoam2006-201012-201012.fc32.x86_64
=============================================================================================
Package Arch Version Repository Size
=============================================================================================
Skipping packages with broken dependencies:
openfoam2006
x86_64 201012-201012.fc32 copr:copr.fedorainfracloud.org:openfoam:openfoam 83 M
Transaction Summary
=============================================================================================
Skip 1 Package
Nothing to do.
Complete!
```
### What is the expected *correct* behavior?
dnf install should complete successfully.
### 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
- OpenFOAM version : openfoam2006-common-201012-201012.fc32.noarch
- Operating system : fedora32 5.8.15-201.fc32.x86_64 #1 SMP Thu Oct 15 15:56:44 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
- Hardware info : x86_64
- Compiler : gccPawan GhildiyalPawan Ghildiyalhttps://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 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/1899vortexShed tutorial - noise utility returns nonsense to SPL and PSD files2021-03-22T21:51:07ZMatej FormanvortexShed tutorial - noise utility returns nonsense to SPL and PSD files
### Summary
Noise utility at vortexShed tutorial when run on points or on surface returns files with negative decibels (inverse and wrong values)
in a frequency range from 0-50.
### Steps to reproduce
<!-- How one can reproduce the ...
### Summary
Noise utility at vortexShed tutorial when run on points or on surface returns files with negative decibels (inverse and wrong values)
in a frequency range from 0-50.
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
### Example case
$FOAM_TUTORIALS/incompressible/pimpleFoam/LES/vortexShed
### What is the current *bug* behaviour?
The bug is most probably in the noise utility. At least on arm64 it returns SPL and PDBs with negative decibels.
I am pretty sure the vortex shedding is not an active silencer.
SPL:
gnuplot> plot 'SPL_dB_f.xy' w l
```
-20 +--------------------------------------------------------------------+
| + + + |
-40 |-+ *** 'SPL_dB_f.xy' *******-|
| ** * |
| ** * |
-60 |-+ ** * +-|
| **** * |
-80 |** ** +-|
| * |
| *** |
-100 |-+ * * +-|
| ** |
-120 |-+ *** +-|
| **** * |
| ***** * * * * * ***** * * |
-140 |-+ ************************************|
| *********************************|
-160 |-+ ************** ***************|
| * ****** * ** * * |
| + + + |
-180 +--------------------------------------------------------------------+
0.1 1 10
```
### Environment information
- OpenFOAM version : 2006
- Operating system : ubuntu 1804
- Hardware info : arm64 (Popeye03)
- Compiler : gcc (system one)
### Possible fixeshttps://develop.openfoam.com/Development/openfoam/-/issues/1900v2006 atmWallConditions produce double value entries2020-12-08T09:38:07ZMark Van Cv2006 atmWallConditions produce double value entries<!--
*** 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 running a case utilizing some of the new atmBoundaryLayer wall functions (I verified this for atmOmegaWallFunction and atmNutkWallFunction but others might present the same issue), the patches defined by these functions contain double value field entries causing an error upon opening in ParaView (5.8.1 on Windows 10).
### Steps to reproduce
<!-- How one can reproduce the issue - this is very important -->
Run any case using either the atmNutkWallFunction or atmOmegaWallFunction boundary definitions.
### 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 -->
The boundary fields defined with either of these wall functions contain duplicate <value> entries, causing errors when opening the case in ParaView. In case of the atmNutkWallFunction for example:
```
boundaryField
{
bottom
{
type atmNutkWallFunction;
value nonuniform List<scalar>
19200
(
...
)
;
boundNut false;
z0 0.003;
value nonuniform List<scalar>
19200
(
...
)
;
};
```
### What is the expected *correct* behavior?
<!-- What you should see instead -->
The value entry should be written only once per boundary patch.
### 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 : WSL 20.04 (Ubuntu 20.04 shell on Windows 10 1909)
- Hardware info : N/A
- Compiler : gcc 6.3.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
-->
[atmNutkWallFunctionFvPatchScalarField.C L201](https://develop.openfoam.com/Development/openfoam/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmNutkWallFunction/atmNutkWallFunctionFvPatchScalarField.C#L201)
[atmOmegaWallFunctionFvPatchScalarField.C L199](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmOmegaWallFunction/atmOmegaWallFunctionFvPatchScalarField.C#L199)
A possible workaround might be to change `nutkWallFunctionFvPatchScalarField::write(os);` and `omegaWallFunctionFvPatchScalarField::write(os);` to `fvPatchField<scalar>::write(os);`.
I extracted this potential fix from [atmAlphatkWallFunctionFvPatchScalarField.C](https://develop.openfoam.com/Development/openfoam/-/blob/OpenFOAM-v2006/src/atmosphericModels/derivedFvPatchFields/wallFunctions/atmAlphatkWallFunction/atmAlphatkWallFunctionFvPatchScalarField.C#L288).v2012Kutalmış BerçinKutalmış Berçinhttps://develop.openfoam.com/Development/openfoam/-/issues/1901Add searchable spheroid2020-10-29T08:14:54ZMark OLESENAdd searchable spheroidThis is an idea that I discussed offline with @Mattijs. Having spheroid as a shape could be useful for external surroundings etc. Found some ideas, but equally importantly I have someone willing to implement it (@victorOle). The first ef...This is an idea that I discussed offline with @Mattijs. Having spheroid as a shape could be useful for external surroundings etc. Found some ideas, but equally importantly I have someone willing to implement it (@victorOle). The first efforts look good, but would likely make most sense to merge into searchableSphere and treat the uniform radii as a special optimized case.
Largely able to work from [Geometric Tools](https://www.geometrictools.com/Documentation/DistancePointEllipseEllipsoid.pdf) documentation (CC-BY 4.0), but needs rework for the OpenFOAM frameworkMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1902Missing Debian packages for Ubuntu 20.10 (groovy)2021-05-04T10:02:53ZGerasimos ChourdakisMissing Debian packages for Ubuntu 20.10 (groovy)### Functionality to add/problem to solve
Binary packages for Ubuntu 20.10 Groovy Gorilla (published on October 22, 2020), next to the current offers for the LTS versions.
### Target audience
Me (:sweat_smile:) and anyone else on the ...### Functionality to add/problem to solve
Binary packages for Ubuntu 20.10 Groovy Gorilla (published on October 22, 2020), next to the current offers for the LTS versions.
### Target audience
Me (:sweat_smile:) and anyone else on the non-LTS Ubuntu (& co.) cycle.
### Proposal
I guess there is a pipeline in place for this, so I though I would nudge the keyholder to trigger it. If there is a way I can help (with some guidance), I would be happy to.
This should be done ince every six months. Next expected dates: April 22, 2021 and October 14, 2021. It is perfectly fine to create the packages even earlier (e.g. with the first beta or RC), usually not much changes after these points.
### What does success look like, and how can we measure that?
A `dists/groovy` on the [official repositories](https://dl.openfoam.com/repos/deb/).
### Links / references
- [Ubuntu 20.10 release notes](https://discourse.ubuntu.com/t/groovy-gorilla-release-notes/15533)
- [Ubuntu releases schedule](https://wiki.ubuntu.com/Releases)
### Funding
None.https://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/1904CentOS precompiled packages don't include scotch2024-01-10T11:27:31ZCristóbal TapiaCentOS precompiled packages don't include scotchHi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDe...Hi,
I installed OpenFOAM v2006 with the instructions provided for CentOS in [1]. However, the `decomposePar` command is not working and gives the following error:
```
--> FOAM FATAL ERROR:
Attempted to use <scotch> without the scotchDecomp library loaded.
This message is from the dummy scotchDecomp stub library instead.
Please install <scotch> and ensure libscotch.so is in LD_LIBRARY_PATH.
The scotchDecomp library can then be built from src/parallel/decompose/scotchDecomp.
Dynamically loading or linking this library will add <scotch> as a decomposition method.
```
Scotch is installed in the system, but I suppose that there is something else missing. Does this has to do with the "Third-Party" builds (not included in the packages?).
[1] https://develop.openfoam.com/Development/openfoam/-/wikis/precompiled/redhathttps://develop.openfoam.com/Development/openfoam/-/issues/1906extensions for PDRblockMesh2021-12-02T17:48:47ZMark OLESENextensions for PDRblockMeshAs noted off-line and EP1247, to be truly useful the PDRblockMesh requires an outer expansion zone. @PratapAs noted off-line and EP1247, to be truly useful the PDRblockMesh requires an outer expansion zone. @Pratapv2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1907PDRsetFields fails with non-orthogonal outer region2020-11-17T12:06:53ZMark OLESENPDRsetFields fails with non-orthogonal outer regionnoticed while testing #1906noticed while testing #1906Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1910rationalize mpi config tuning2020-11-17T12:06:14ZMark OLESENrationalize mpi config tuningThe tuning of mpi parameters is difficult to distinguish from regular configurations.
Eg, `config.sh/mpi` vs `config.sh/openmpi`.
I would propose that we unify this with a common prefix or suffix.
My current tendency is with a prefix, t...The tuning of mpi parameters is difficult to distinguish from regular configurations.
Eg, `config.sh/mpi` vs `config.sh/openmpi`.
I would propose that we unify this with a common prefix or suffix.
My current tendency is with a prefix, to have nicely sorted items. The prefix `tune.` looks nice to me, but `prefs.` is probably better since it bears resemblance to `prefs.sh` etc.
After the change, we could add in additional preference tuning for mpich, intelmpi etc. The optional files would then look like this:
- config.sh/prefs.mpich
- config.sh/prefs.openmpi
- config.sh/prefs.openmpi-system
- ...
This mostly affects @Prashant and perhaps @Pawan I would suspect.v2012Mark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1911update config for newer ADIOS2 library names2020-12-24T10:27:54ZMark OLESENupdate config for newer ADIOS2 library namesMark OLESENMark OLESENhttps://develop.openfoam.com/Development/openfoam/-/issues/1912Compiling OpenFOAM v.20062020-11-10T12:10:41ZTasman Van LoonCompiling OpenFOAM v.2006Hi there, I'm trying to compile OpenFOAM v.2006 and have followed the instructions as per this webpage:
https://develop.openfoam.com/Development/openfoam/blob/develop/doc/Build.md
There are no issues with the foamSystemCheck. But when I...Hi there, I'm trying to compile OpenFOAM v.2006 and have followed the instructions as per this webpage:
https://develop.openfoam.com/Development/openfoam/blob/develop/doc/Build.md
There are no issues with the foamSystemCheck. But when I go to execute the ./Allwmake command, there is an error message (which I have attached).
Any advice would be appreciated!
Kind regards,
Tasman. ![Screen_Shot_2020-11-05_at_11.04.27_pm](/uploads/60136129f5c4821f4a97e5281f02c7b7/Screen_Shot_2020-11-05_at_11.04.27_pm.png)https://develop.openfoam.com/Development/openfoam/-/issues/1913SolidificationMeltingSource acts different on 2D and 3D2020-11-13T10:41:39ZEren ColakSolidificationMeltingSource acts different on 2D and 3D<!--
*** Please read this first! ***
B[SolidMeltSource.7z](/uploads/dab9f2ec6ea41b67fd1a825073253679/SolidMeltSource.7z)
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summar...<!--
*** Please read this first! ***
B[SolidMeltSource.7z](/uploads/dab9f2ec6ea41b67fd1a825073253679/SolidMeltSource.7z)
-->
<!--
All text between these markers are comments and will not be present in the
report
-->
### Summary
SolidificationMeltingSource gives different results with 2D and 3D solutions. While 3D solution gives accurate results there is no change in the z direction(3rd direction). So it makes no sense and increases the computational time up to 10 times.
### Steps to reproduce
just run buoyantPimpleFoam for test cases I sent. Files also contains some of the results.
### 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?
Somehow "Benard Cells" appears in 2D case and it changes melting front drastically.
### What is the expected *correct* behavior?
There should be no "Benard Cells" so melting front will be like 3D case I attached.
### 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
- OpenFOAM version : v2002
- Operating system : ubuntu 18.04
- Hardware info : ryzen 5 3600
- Compiler : gcc
### Possible fixes
I have no idea about this.[SolidMeltSource.7z](/uploads/bcf207105fb5bded154a3552c4cb5fc8/SolidMeltSource.7z)https://develop.openfoam.com/Development/openfoam/-/issues/1914Loading the OpenFOAM bashrc by default makes the Ubuntu 20.10 desktop unale t...2024-01-09T12:16:04ZGerasimos ChourdakisLoading the OpenFOAM bashrc by default makes the Ubuntu 20.10 desktop unale to load (X11-only)I stumbled upon a very weird issue that I can consistently reproduce on the same system. After installing OpenFOAM v2006 on Ubuntu 20.10 (see #1902) and adding `source "/usr/lib/openfoam/openfoam2006/etc/bashrc"` to my `~/.bashrc`, my de...I stumbled upon a very weird issue that I can consistently reproduce on the same system. After installing OpenFOAM v2006 on Ubuntu 20.10 (see #1902) and adding `source "/usr/lib/openfoam/openfoam2006/etc/bashrc"` to my `~/.bashrc`, my desktop fails to launch in X11, while it loads normally on Wayland.
There is no error, the system simply returns to the login screen after a few seconds. Removing this line from my `~/.bashrc` or making it an alias (so that I load it on demand) fixes the issue.
Any clue why this could happening? Can you reproduce it?